Re: Weird return-value from pg_get_function_identity_arguments() on certain aggregate functions?

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> On Mon, Mar 12, 2018 at 2:19 PM, P O'Toole <P(dot)OToole(at)uwyo(dot)edu> wrote:
>>> According to the System Information Functions docs,
>>> pg_get_function_identity_arguments(OID) should simply "get argument list
>>> to identify a function (without default values)", but one example of how it
>>> behaves strangely is that:

> In this case I'd say the supposed bug is that GRANT ON FUNCTION doesn't
> accept the signature of a valid CREATE AGGREGATE​ even though our existing
> implementation uses it as an implementation mechanism for both (i.e., we
> don't have a separate GRANT ON AGGREGATE).

The entire point of pg_get_function_identity_arguments is that it's
supposed to print the arguments in the form that would be accepted by
GRANT, as well as DROP FUNCTION and some other commands, so I'd tend
to blame pg_get_function_identity_arguments. Probably the reason
nobody has noticed up to now is a dearth of user-defined ordered-set
functions. Still, we're supposed to support such things, so we
oughta fix it.

[ pokes at it ... ] Hmm, DROP AGGREGATE will let you spell it
either way, so maybe it is indeed only GRANT that's got an issue.
If so, perhaps allowing this syntax there is an attractive fix.
In theory there might be pg_dump files out there using this syntax.

regards, tom lane