Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> Regardless of that, though ... what is the reasoning for
> Tom> inventing pg_get_aggregate_arguments() rather than just making
> Tom> pg_get_function_arguments() do the right thing?
> pg_get_function_arguments()'s interface assumes that the caller is
> providing the enclosing parens. Changing it would have meant returning
> a result like 'float8) WITHIN GROUP (float8' which I reckoned would
> have too much chance of breaking existing callers.
Well, as it stands, existing callers are broken a fortiori; they can't
possibly produce the right output for an ordered-set aggregate, if we
define the "right output" as looking like that. Of course, if we define
the right output as being just the arguments according to pg_proc, it's
fine. But your point about the parens is a good one anyway, because now
that I think about it, what \da has traditionally printed is
pg_catalog | sum | bigint | integer | sum as bigint acro
ss all integer input values
and I see the patch makes it do this
pg_catalog | sum | bigint | (integer) | sum as bigint acro
which I cannot find to be an improvement, especially since \df does
not look like that. (As patched, the output of "\df ran*" is positively
schizophrenic.)
One possibility is to forget all the parens and say that the display
looks like
type1, type2 WITHIN GROUP type3, type4
Please don't object that that doesn't look exactly like the syntax
for calling the function, because it doesn't anyway --- remember you
also need ORDER BY in the call.
Or perhaps we could abbreviate that --- maybe just WITHIN? Abbreviation
would be a good thing, especially if we're going to say 'VARIADIC "any"'
twice in common cases. OTOH I'm not sure we can make that work as a
declaration syntax without reserving WITHIN. I think WITHIN GROUP would
work, though I've not tried to see if bison likes it.
Anyway, the long and the short of this is that the SQL committee's bizarre
choice of syntax for calling these functions should not be followed too
slavishly when declaring them.
regards, tom lane