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