Re: wip: functions median and percentile - Mailing list pgsql-hackers

From Hitoshi Harada
Subject Re: wip: functions median and percentile
Date
Msg-id AANLkTikepCe+eSOgu_wHA1jACs94FyVrRoTN6N0FZG9M@mail.gmail.com
Whole thread Raw
In response to Re: wip: functions median and percentile  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: wip: functions median and percentile
Re: wip: functions median and percentile
List pgsql-hackers
2010/10/12 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> 2010/10/11 Greg Stark <gsstark@mit.edu>:
>> On Sun, Oct 10, 2010 at 2:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> It was pointed out upthread that while median isn't presently
>>> in the standard, Oracle defines it in terms of percentile_cont(0.5)
>>> which *is* in the standard.
>>
>> Uhmm, then why don't we implement that? We could provide median() as a
>> short-cut but percentile_cont() doesn't sound much harder to implement
>> than median() and more general.
>
> The problem is in interface. The original patch did it, but I removed
> it. We cannot to unsure immutability of some parameters now. Can we
> enhance a AGGREGATE to allow some mark like IMMUTABLE parameter and
> probably we should to support ANSI syntax:
>
> PERCENTILE_CONT ( expression1 )
> WITHIN GROUP ( ORDER BY expression2 [ ASC | DESC ] )
>
> This syntax allows to divide a muttable and immutable parameters.

If this is only a syntax sugar for mutable/immutable parameter, then I
guess it's time to take it serious to implement in our syntax,
although I'm not sure if it affects more execution model than
interface.

Regards,



-- 
Hitoshi Harada


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: security hook on table creation
Next
From: KaiGai Kohei
Date:
Subject: Re: leaky views, yet again