Re: Variadic aggregates vs. project policy

2013/8/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2013/8/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>