Re: Weird quirk with pg_dump of complex types - Mailing list pgsql-bugs

From Jeff Davis
Subject Re: Weird quirk with pg_dump of complex types
Date
Msg-id 1235715314.5294.25.camel@jdavis
Whole thread Raw
In response to Re: Weird quirk with pg_dump of complex types  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Weird quirk with pg_dump of complex types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, 2009-02-26 at 21:42 -0800, Josh Berkus wrote:
> Jeff,
>
> > 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".
>
> Yeah, but for most other objects "public" is also excluded as well as
> pg_catalog.  For CREATE TYPE, "public" is explicit.
>


Ah, I see what you mean. Here's what I get when the type is named
public.integer (pg_dump output):

CREATE FUNCTION f1(x "integer", y integer) RETURNS integer
    LANGUAGE sql
    AS $$ select 1; $$;

and here's what I get when I try to be creative, and I define a
public.tsvector type (pg_dump output):

CREATE FUNCTION f1(x tsvector, y pg_catalog.tsvector) RETURNS integer
    LANGUAGE sql
    AS $$ select 1; $$;

It seems like pg_dump tries fairly hard to make the output readable in
the typical case. It does seem a little inconsistent that the list of
types that make up another type don't follow the exact same rules; I
don't know the reason for that.

Is using the custom format a possibility?

Regards,
    Jeff Davis

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Weird quirk with pg_dump of complex types
Next
From: Tom Lane
Date:
Subject: Re: Weird quirk with pg_dump of complex types