From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Abhijit Menon-Sen <ams(at)oryx(dot)com> |
Cc: | Gavin Sherry <swm(at)alcove(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] "\ef <function>" in psql |
Date: | 2008-07-17 22:28:19 |
Message-ID: | 4311.1216333699@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Abhijit Menon-Sen <ams(at)oryx(dot)com> writes:
> Though I must say it would have been even MORE horrible to copy all this
> code into the backend to make pg_get_functiondef(), notwithstanding the
> extra utility of a generally-callable function.
FWIW, I just found myself forced to invent pg_get_function_arguments()
and pg_get_function_result(), because the TABLE function patch has
pushed the complexity of printing function argument and result types
well beyond the bounds of sanity. (Pavel had hacked up pg_dump and
ignored psql's \df ...) It wouldn't take a whole lot to convince me
that a pg_get_functiondef would be useful, although I don't foresee
either of those applications wanting to use it because of their
backward-compatibility constraints.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Munro | 2008-07-17 22:52:29 | Patch to eliminate duplicate b64 code from pgcrypto |
Previous Message | Alvaro Herrera | 2008-07-17 21:18:16 | Re: ecpg generated files ignorable? |