2013/8/29 Tom Lane <t...@sss.pgh.pa.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+gsapte3n6tjq1jpphmzhg2...@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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
