Re: Aggregate ORDER BY patch

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Aggregate ORDER BY patch
Date: 2009-11-16 04:49:17
Message-ID: e08cc0400911152049m67af44cbh6fcf49006aa63b87@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/11/16 Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>:
>>>>>> "Hitoshi" == Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
>
>  >> What case exactly would you consider an error? When an order by
>  >> expression references a lower (more deeply nested) query level
>  >> than any of the actual arguments?
>
>  Hitoshi> It's only that I felt not intuitive. To me, arguments are
>  Hitoshi> regarded as aggregate's "member" while ORDER BY clause
>  Hitoshi> expressions didn't hit me.  If it's only me, no
>  Hitoshi> problem. Maybe additional document in #syntax-aggregates
>  Hitoshi> will do.
>
> How about:
>
>    ... But an exception occurs if the aggregate's arguments
>    (including any <literal>ORDER BY</> clause) contain only
>    outer-level variables: the aggregate then belongs to the nearest
>    such outer level, ...

Reasonable. Thank you.

>  Hitoshi> I don't have much experiences in VIEW systems, but isn't it
>  Hitoshi> enough to let "order by x" omitted? "select count(distinct x
>  Hitoshi> order by x) from table" means the same as "select
>  Hitoshi> count(distinct x) from table" currently. ruleutils can
>  Hitoshi> handle it if distinct expressions are equal to order by
>  Hitoshi> expressions.
>
> That doesn't work in more complex cases. For example, the user might
> specify aggfunc(distinct x,y order by x) (not caring about the relative
> order of y) but the code will still turn that internally into
> aggfunc(distinct x,y order by x,y). It's necessary to be able to recover
> what the user originally entered, which means needing to be able to
> distinguish both of those cases from aggfunc(distinct x,y).
>
With Tom's comment, this issue is closed now with some hope that
author will see if new code can be shared with traditional code once
more.

So I guess all of my review comments are get done. Could you update
your patch with doc patch in it? After that I'll test it again and
will mark this as "Ready for Committer" if no objection nor no problem
found.

Regards,

--
Hitoshi Harada

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-11-16 04:51:28 Re: named parameters in SQL functions
Previous Message Pavel Stehule 2009-11-16 04:46:57 Re: named parameters in SQL functions