Re: [Haskelldb-users] haskelldb, LIMIT, OFFSET, DISTINCT

[Justin B. <jgb...@gm...>]

On Wed, Apr 2, 2008 at 9:48 PM, Peter Gammie <pe...@gm...> wrote:
> Bjorn,
>
>  I'm confused by the "unique" function. Why does it not just use SELECT
>  DISTINCT <blah>? GROUP BY semantics are filthy.

I can speak to unique, as I provided the patch which implemented it
(http://tinyurl.com/2u9hmf). When I started with haskelldb, it added
"distinct" to all queries. That behavior didn't work for what I wanted
to do. I coded unique so 'distinct' behavior was still accessible, but
wasn't the default. My experience with SQL has been to use GROUP BY
over DISTINCT, which is why it generates the code it does. What makes
GROUP BY filthy?

>  roughly I am trying to pass an aggregation function around and when I
>  use it in a record construction I get this problem.

I ran a problem when passing around aggregates recently that didn't
group quite correctly - the SQL was correct but the query result was
not. It's referenced in this email (http://tinyurl.com/33apbb) - are
you seeing the same thing?

>
>  Here's a plan: Add a new function:
>
>  project' :: [Opt] -> ... blah, same as project
>
>  where
>
>  data Opt = DISTINCT | LIMIT Int | OFFSET Int
>
>  I want to specify that these Opts apply to *this* projection, i.e. we
>  need to track the column names passed to project'. I propose to do
>  this by hacking the Project constructor in PrimQuery:
>
>  data PrimQuery = ... | Project Assoc PrimQuery | ...
>
>  becomes
>
>  data PrimQuery = ... | Project [Opt] Assoc Assoc PrimQuery | ...

Have you considered wrangling the existing Special value to do this?
It already handles "TOP" and "ORDER". However, ORDER BY seems to get
propogated out to the outermost select so maybe it's not feasible.

Justin