From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Weird quirk with pg_dump of complex types |
Date: | 2009-02-27 05:19:55 |
Message-ID: | 1235711995.5294.16.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-02-27 05:42:30 | Re: Weird quirk with pg_dump of complex types |
Previous Message | John R Pierce | 2009-02-27 02:24:48 | Re: Support platform of PostgresSQL 8.1.9 under IBM AIX 5.3 |