Re: Variadic aggregates vs. project policy

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

> So I was hacking away at supporting variadic aggregates (per an internal
> request at Salesforce), and had it pretty much working, when I came across
> this old comment in opr_sanity.sql:
>
> -- Check that there are not aggregates with the same name and different
> -- numbers of arguments. While not technically wrong, we have a project
> policy
> -- to avoid this because it opens the door for confusion in connection with
> -- ORDER BY: novices frequently put the ORDER BY in the wrong place.
> -- See the fate of the single-argument form of string_agg() for history.
> -- The only aggregates that should show up here are count(x) and count(*).
>
> While a variadic-using aggregate doesn't actually trip the associated test
> query, it surely violates the spirit of this policy: if you put ORDER BY
> in the wrong place the parser will be unable to detect that that wasn't
> what you meant.
>
> For context see the thread starting here:
>
> http://www.postgresql.org/message-id/AANLkTikV5ok2tS8t6V+gsAPtE3N6TJq1JpPhMZhG2XL0@mail.gmail.com
> In that thread we agreed that this "policy" might be rather squishy,
> but we should at least think hard about whether it would be wise to create
> built-in aggregates with the same name and different numbers of arguments.
>
> 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.

Regards

Pavel

> regards, tom lane
>
>
> --
> 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
>