Re: Variadic aggregates vs. project policy - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Variadic aggregates vs. project policy
Date
Msg-id CAFj8pRCXJo79usnVGgu3WEjNqSVVX6fSg31qXyqAkgPNg_JZcQ@mail.gmail.com
Whole thread Raw
In response to Re: Variadic aggregates vs. project policy  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers



2013/8/29 Tom Lane <tgl@sss.pgh.pa.us>
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2013/8/29 Tom Lane <tgl@sss.pgh.pa.us>
>> So the question I'm now wondering about is whether this consideration
>> makes variadic aggregates a bad idea all around, even if we don't have
>> any built-in ones.  Is the risk of user confusion (in the use of their
>> own aggregate) sufficient reason to reject such a feature?

> can be this issue solved by syntax?
> In September commitfest is  patch for "WITHIN GROUP" where ORDER BY clause
> is safety separated from parameters.

That might not be the ugliest syntax the SQL committee ever invented, but
it's right up there.  I don't want to go that way, especially not when the
existing precedent for the same feature with regular functions doesn't use
any weird special syntax.

It is maybe not nice, but it is long years supported by almost all SQL servers.

When I talked with Atri, he mentioned, so variadic aggregates are supported there too.
 
Regards

Pavel


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.


can be this potentially strange situation identified? - and some warning can be raised.

 


 
                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Variadic aggregates vs. project policy
Next
From: "David E. Wheeler"
Date:
Subject: Re: PL/pgSQL PERFORM with CTE