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

From Hitoshi Harada
Subject Re: Aggregate ORDER BY patch
Date
Msg-id e08cc0400911131031t4fbeedd0mc32fca3879e61cc6@mail.gmail.com
Whole thread Raw
In response to Re: Aggregate ORDER BY patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/11/14 Tom Lane <tgl@sss.pgh.pa.us>:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> "Peter" == Peter Eisentraut <peter_e@gmx.net> writes:
>>  Peter> This is exactly the syntax that is in the spec AFAICT.
>
>> Right. The spec defines this syntax for array_agg and xmlagg (only).
>
> Cool, I had forgotten that they added that in the latest revisions.
> I withdraw the complaint that this patch goes too far beyond the spec.
>
>> But it would be entirely unreasonable, the way postgres works, to
>> implement ORDER BY for only specific aggregates.
>
> Quite.  This is another instance of the thing I complained of before,
> that the SQL committee likes to define the behavior of specific
> aggregates instead of inducing a generic aggregate-behavior definition.
> So we're on our own to extract one, and this proposal seems pretty
> reasonable to me: it's useful and it's consistent with the query-level
> behavior of DISTINCT and ORDER BY.
It's not only in aggregates but also window function as well as plain
functions like substring(x from t). In window functions, IGNORE NULLS
is defined in spec for those first_vlaue(), last_value(), lead(),
lag(), etc. but not for generic use. I'm +1 for an approach to apply
them for generic cases.

Regards,

--
Hitoshi Harada


pgsql-hackers by date:

Previous
From: nw@hydaspes.if.org
Date:
Subject: Re: next CommitFest
Next
From: Alvaro Herrera
Date:
Subject: Re: Experimental patch: generating BKI revisited