Re: Aggregate ORDER BY patch - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: Aggregate ORDER BY patch
Date
Msg-id e08cc0400911152049m67af44cbh6fcf49006aa63b87@mail.gmail.com
Whole thread Raw
In response to Re: Aggregate ORDER BY patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
2009/11/16 Andrew Gierth <andrew@tao11.riddles.org.uk>:
>>>>>> "Hitoshi" == Hitoshi Harada <umi.tanuki@gmail.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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: named parameters in SQL functions
Next
From: Pavel Stehule
Date:
Subject: Re: named parameters in SQL functions