Re: [PATCH] "\ef " in psql - Mailing list pgsql-hackers

From Asko Oja
Subject Re: [PATCH] "\ef " in psql
Date
Msg-id ecd779860807290352rc6e263bu71b327f69c03993f@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] "\ef " in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Marko is talking about types created with CREATE TYPE

CREATE FUNCTION fraud.get_user_status(
    i_key_user text
    ) RETURNS ret_get_user_status AS
$$

Current pg_dump annoyingly removes schem reference from type.

On Wed, Jul 23, 2008 at 6:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Marko Kreen" <markokr@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: [PATCH] "\ef " in psql
Next
From: "Stephen R. van den Berg"
Date:
Subject: Relicensed and downloadable (Re: Protocol 3, Execute, maxrows to return, impact?)