Re: Weird quirk with pg_dump of complex types

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