Re: Variadic aggregates vs. project policy

2013/8/30 Andrew Dunstan <andrew(at)dunslane(dot)net>

>
> On 08/29/2013 05:37 PM, Josh Berkus wrote:
>
>> Tom,
>>
>> On further reflection, what the "policy" was actually about was not that
>>> we should forbid users from creating potentially-confusing aggregates
>>> themselves, but only that we'd avoid having any *built in* aggregates
>>> with
>>> this hazard. So maybe I'm overthinking this, and the correct reading is
>>> just that we should have a policy against built-in variadic aggregates.
>>>
>> Yes. I think we can assume that anyone smart enough to create a
>> variadic aggregate is smart enough to put ORDER BY in the right place.
>>
>>
>>
> It's not the creator who is in danger, though, it's the user of the
> aggregate function, AIUI. So unless you're saying that anyone smart enough
> to use a variadic aggregate can be assumed to be smart enough to put ORDER
> BY in the right place, I don't think this argument holds.
>

I was one who sent a bug report - this error is not too dangerous, but it
is hidden, and difficult to find, if you don't know what can be happen.
Same as bug with plpgsql and SQL identifier collisions. If you understand,
then you can protect self well and simply. If not, then it is a magic
error. So still I am thing so best solution is

a) a warning when detect ORDER BY in variadic aggregates

b) disallow ORDER BY in variadic aggregates in classic syntax, and enable
it only in WITHIN GROUP syntax where is safe , btw a aggregates that needs
a ORDER BY is better to evaluate different for minimise risk of OOP killer.
This is a good solution without any risks.

Regards

Pavel

>
> cheers
>
> andrew
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-hackers<http://www.postgresql.org/mailpref/pgsql-hackers>
>