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: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Aggregate ORDER BY patch
Date: 2009-11-13 18:26:00
Message-ID: e08cc0400911131026w8098543y75f3c0f10d4dcf4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/11/14 Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>:
>>>>>> "Heikki" == Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>
>  >> No artificial restrictions are imposed on what syntactical
>  >> combinations are allowed. However, ORDER BY is not allowed with
>  >> aggregates used as window functions (as per the existing
>  >> restriction on DISTINCT).
>
>  Heikki> How is this different from window functions?
>
> Window functions return a row for each row of input, aggregates don't.
>
> The reason I didn't tackle the case of aggregate functions used as
> window functions is that the spec allows constructs like this:
>
> array_agg(a order by b) over (order by c)
>
> which can't be represented using the aggregate-as-window-function
> mechanism as it currently stands, since you'd have to re-sort the
> window each time.
>
Now I'm about to send my patch to introduce more frame types,
aggregate cache mechanism in window functions may be broken sometimes,
and it is *possible* to put order-by clause in argument list if we
prepare tuplesort as in nodeAgg. But I don't see useful cases and it
seems so hard task that I'm not sold.

Regards,

--
Hitoshi Harada

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message James Pye 2009-11-13 18:27:06 Re: Python 3.1 support
Previous Message Andrew Chernow 2009-11-13 18:19:02 Re: Listen / Notify rewrite