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