Skip site navigation (1) Skip section navigation (2)

Re: Weird quirk with pg_dump of complex types

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 06:15:14
Message-ID: 1235715314.5294.25.camel@jdavis (view raw or flat)
Thread:
Lists: 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


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-02-27 06:24:50
Subject: Re: Weird quirk with pg_dump of complex types
Previous:From: Tom LaneDate: 2009-02-27 05:50:14
Subject: Re: Weird quirk with pg_dump of complex types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group