Re: usability of pg_get_function_arguments

Gevik Babakhani <pgdev(at)xs4all(dot)nl> writes:
> Perhaps it would be much better if pg_get_function_arguments returned
> the data is some kind of a structure than a blob of string like the above.

That would be more work, not less, for the known existing users of the
function (namely pg_dump and psql). It's a bit late to be redesigning
the function's API anyway.

> In order to make the data above usable, one has to write a custom parser
> to hopefully be able to make any use of the return data. Of course
> another option is to parse the pg_proc.proargdefaults
> which in turn is a challenge on its own.

The recommended way to do that is to use pg_get_expr --- it'd certainly
be a bad idea to try to parse that string from client code.

I experimented with your example and noticed that pg_get_expr requires a
hack --- it insists on having a relation OID argument, because all
previous use-cases for it involved expressions that might possibly refer
to a particular table. So you have to do something like

regression=# select pg_get_expr(proargdefaults,'pg_proc'::regclass) from pg_proc where proname='f13';
pg_get_expr
-----------------------------------------------------------------------------------------------------------------------
10, 'hello'::character varying, '2009-01-01 00:00:00'::timestamp without time zone, 'comma here ,'::character varying
(1 row)

where it doesn't matter which table you name, as long as you name one.
It would probably be cleaner to allow pg_get_expr to accept a zero OID,
for use when you are asking it to deparse an expression that's expected
to be Var-free.

regards, tom lane