From: Tom Lane on
Abhijit Menon-Sen <ams(a)oryx.com> writes:
> At 2008-07-17 18:28:19 -0400, tgl(a)sss.pgh.pa.us wrote:
>> 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.

> What would the function return? "CREATE OR REPLACE FUNCTION ..."? Would
> that be good enough for everyone who might want to call it?

I think I'd go with CREATE FUNCTION for simplicity. It would be easy
enough for something like \ef to splice in OR REPLACE before shipping
the command back to the server.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Marko Kreen" on
On 7/23/08, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Abhijit Menon-Sen <ams(a)oryx.com> writes:
> > At 2008-07-17 18:28:19 -0400, tgl(a)sss.pgh.pa.us wrote:
> >> 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.
>
> > What would the function return? "CREATE OR REPLACE FUNCTION ..."? Would
> > that be good enough for everyone who might want to call it?
>
> I think I'd go with CREATE FUNCTION for simplicity. It would be easy
> enough for something like \ef to splice in OR REPLACE before shipping
> the command back to the server.

Please make it use full qualified names (schema.name) for both
function name and result types. Current search_path juggling
the pg_dump does is major PITA.

--
marko

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on
"Marko Kreen" <markokr(a)gmail.com> writes:
>> [ re pg_get_functiondef ]

> Please make it use full qualified names (schema.name) for both
> function name and result types. Current search_path juggling
> the pg_dump does is major PITA.

Qualifying the function name seems like a good idea, but I'd advise
against tinkering with the datatype references. It'll be hard to
do correctly and it will make things very substantially uglier.
Do you really want to show, eg, "pg_catalog.int4" rather than "integer"?

If you leave the backend code do what it wants to do here, the only
way that there would be a problem is if someone changed their
search_path in between pg_get_functiondef and trying to re-load the
function definition. Which certainly ain't gonna happen for \ef,
and it seems a bit implausible for any other use-case either.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Abhijit Menon-Sen on
At 2008-07-23 10:50:03 -0400, tgl(a)sss.pgh.pa.us wrote:
>
> > What would the function return? "CREATE OR REPLACE FUNCTION ..."?
>
> I think I'd go with CREATE FUNCTION for simplicity.

OK, I have a mostly working pg_get_functiondef now, and some questions
about the remaining pieces:

1. Why is "prorows" a float4? Should I print it that way, i.e. "%f"?

2. Can I print the contents of "proconfig" as just "SET %s"? It seems
to work for the variables I've tried (e.g. "DateStyle=iso"), but I
wonder if they'll always be quoted correctly (i.e., if the "split
on '='" thing pg_dump does is necessary for an 8.4 function).

3. Is there a function I can use from ruleutils.c to do dollar quoting
of prosrc/probin? If not, and I have to write one, where should it
live?

4. What exactly is probin? Do I need to worry about it at all?

Thanks.

-- ams

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Robert Haas" on
+1 for CREATE OR REPLACE

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers