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