2010/8/18 David Fetter <david@fetter.org>:
> On Wed, Aug 18, 2010 at 04:03:25PM +0200, Pavel Stehule wrote:
>> 2010/8/18 Tom Lane <tgl@sss.pgh.pa.us>:
>> > Pavel Stehule <pavel.stehule@gmail.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.
>
> Which median do you plan to implement? Or do you plan to implement
> several different medians, each with distinguishing names?
my proposal enabled implementation of any "median like" function. But
if we implement median as special case of aggregate, then some basic
"median" will be implemented.
Regards
Pavel
>
> Cheers,
> David.
> --
> David Fetter <david@fetter.org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david.fetter@gmail.com
> iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
