I don't especially like the syntax you invented for listing arguments in CREATE AGGREGATE, especially not the WITHIN GROUP (*) special case. If we stick with that we're going to need to touch a lot more places than you have, notably regprocedure. I also fear that this syntax is not appropriate for identifying aggregates reliably, ie, aggregate argument lists that look different in this syntax could reduce to identical pg_proc.proargs lists, and perhaps vice versa.
I think we should just have it list the arguments as they'd appear in pg_proc, and rely on aggregate properties (to wit, aggkind and aggndirectargs) to identify ordered-set and hypothetical aggregates. A slightly different question is what \da ought to print. I can't say I think that (VARIADIC "any") WITHIN GROUP (*) is going to prove very helpful to users, but probably just (VARIADIC "any") isn't going to do either, at least not unless we add an aggregate-kind column to the printout, and maybe not even then. It might work to cheat by duplicating the last item if it's variadic: (..., VARIADIC "any") WITHIN GROUP (VARIADIC "any") while if it's not variadic, we'd have to work out which argument positions correspond to the ordered-set arguments and put them in the right places. Regardless of that, though ... what is the reasoning for inventing pg_get_aggregate_arguments() rather than just making pg_get_function_arguments() do the right thing? The separate function seems to accomplish little except complicating life for clients, eg in psql's describe.c. 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