Re: [PATCH] "\ef " in psql
От | Asko Oja |
---|---|
Тема | Re: [PATCH] "\ef |
Дата | |
Msg-id | ecd779860807290352rc6e263bu71b327f69c03993f@mail.gmail.com обсуждение исходный текст |
Ответ на |
Re: [PATCH] "\ef |
Список | 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.
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 ]Qualifying the function name seems like a good idea, but I'd advise
> 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.
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 по дате отправления: