Re: Weird quirk with pg_dump of complex types
От | Jeff Davis |
---|---|
Тема | Re: Weird quirk with pg_dump of complex types |
Дата | |
Msg-id | 1235711995.5294.16.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Weird quirk with pg_dump of complex types (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Weird quirk with pg_dump of complex types
|
Список | pgsql-bugs |
On Thu, 2009-02-26 at 15:52 -0800, Josh Berkus wrote: > Jeff, > > > Functions are similar, actually. The argument list needs to specify > > schema paths as well, if it's not in some expected place (I think it > > does so for all schemas other than pg_catalog). > > Except that they don't appear to do so. Here is the case I'm talking about: postgres=# create schema a; CREATE SCHEMA postgres=# create type a.int4 as (i pg_catalog.int4); CREATE TYPE postgres=# create function f1(x a.int4, y pg_catalog.int4) returns pg_catalog.int4 language sql as $$ select 1; $$; CREATE FUNCTION -- pg_dump output: SET search_path = public, pg_catalog; ... CREATE FUNCTION f1(x a.int4, y integer) RETURNS integer LANGUAGE sql AS $$ select 1; $$; So, there are some special cases somewhere so that the pg_dump output isn't littered with unreadable "pg_catalog.int4" everywhere. In the general case though, for any object that refers to multiple other objects, I don't see any way around explicit schema qualification. I suppose it could be smart and say "foo_type is unique in my search path, so I don't need to schema-qualify it". Have you considered working from the "custom" format rather than text? I'm not sure whether it solves your problem, but I think it provides the most information. Regards, Jeff Davis
В списке pgsql-bugs по дате отправления: