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.
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.
