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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
