Tom Lane wrote:
Gevik Babakhani writes:
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
Gevik Babakhani writes:
>> 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 somethi
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 f
Gevik Babakhani 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
I am trying to extract function argument information using the
pg_get_function_arguments() and it strikes me that despite of this
function generating very useful information, it is actually not so user
friendly.
Consider the following:
-
create o
