From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: tuplestore, tuplesort aggregate functions |
Date: | 2010-08-18 14:03:25 |
Message-ID: | AANLkTikONwYj9-AVpPhT9TJO82RGc03QhWt07=aLHdOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/8/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> I still thinking about a "median" type functions. My idea is to
>> introduce a new syntax for stype definition - like
>
>> stype = type, or
>> stype = ARRAY OF type [ ORDER [ DESC | ASC ]], or
>> stype = TUPLESTORE OF type, or
>> stype = TUPLESORT OF type [ DESC | ASC ]
>
> This seems like a fairly enormous amount of conceptual (and code)
> infrastructure just to make it possible to build median() out of spare
> parts. It's also exposing some implementation details that I'd just as
> soon not expose in SQL. I'd rather just implement median as a
> special-purpose aggregate.
yes, it is little bit strange - but when we talked last time about
this topic, I understand, so you dislike any special solution for this
functionality. So I searched different more general way. On the other
hand, I agree so special purpose aggregate (with a few changes in
nodeAgg) can be enough. The median (and additional forms) is really
special and there are not wide used use case.
Regards
Pavel
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2010-08-18 14:05:59 | Re: proposal: tuplestore, tuplesort aggregate functions |
Previous Message | Tom Lane | 2010-08-18 13:57:19 | Re: pgsql: Coerce 'unknown' type parameters to the right type in the |