From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Aggregate ORDER BY patch |
Date: | 2009-11-13 15:35:08 |
Message-ID: | 2968.1258126508@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> Andrew Gierth wrote:
>>> Herewith a patch to implement agg(foo ORDER BY bar) with or without
>>> DISTINCT, etc.
>>
>> What does that mean? Aggregate functions are supposed to be commutative,
>> right?
> We certainly have non-commutative agggregates currently, notably array_agg()
Right. The fact that none of the standard aggregates are
order-sensitive doesn't mean that it's not useful to have user-defined
ones that are. Currently we suggest fetching from an ordered sub-select
if you want to use an aggregate that is input order sensitive. This
patch just provides an alternative (and equally nonstandard) notation
for that.
I'm not entirely convinced that adding ORDER BY here is a good idea,
partly because it goes so far beyond the spec and partly because it's
not going to be easily optimizable. But I can see that there is a
use-case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-11-13 15:44:25 | Re: Aggregate ORDER BY patch |
Previous Message | Zdenek Kotala | 2009-11-13 15:29:00 | [Patch] Fix enum type mismatch |