Re: usability of pg_get_function_arguments

> 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.
I agree.

> 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)
>
>
Unfortunately, there is no way to know to which argument(s) the values
above belongs to.
After some searching, it looks like PgAdmin does the trick by hand
parsing the string.

Fortunately the result of pg_get_expr from above is ordered --- Perhaps
by doing some find and replace, I can determine to which argument the
returned default value belongs to.

Thank you for your help :)

--
Regards,
Gevik