Re: Problem with pg_dump -n schemaname - Mailing list pgsql-patches

From Tom Lane
Subject Re: Problem with pg_dump -n schemaname
Date
Msg-id 14866.1195934864@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with pg_dump -n schemaname  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Problem with pg_dump -n schemaname  (Bruce Momjian <bruce@momjian.us>)
List pgsql-patches
Bruce Momjian <bruce@momjian.us> writes:
> The correct solution is to reset AH->currSchema if we we dropped a
> schema.

No it isn't.  This is an ugly, brute-force, misleadingly commented fix.
For one thing, why reset currSchema if it doesn't match the schema
we dropped?  And what if we only drop some member objects and not the
schema itself?  (That may not be possible right now, but it certainly
seems like a likely scenario in future as we extend pg_dump's selective
dump facilities.)

The whole thing is actually pretty subtle.  Zoltan's original proposed
fix is no good because we do have to set the search path to ensure that
component names within a DROP will be resolved properly.  Consider

create schema ss;
create type ss.complex as (x real, y real);
create function ss.realpart(ss.complex) returns real as
  'select $1.x' language sql strict immutable;

pg_dump -c will emit stuff like this:

SET search_path = ss, pg_catalog;

DROP FUNCTION ss.realpart(complex);
DROP TYPE ss.complex;
DROP SCHEMA ss;

That is, the primary name of a DROP target will be fully qualified,
but other names within the command not necessarily.  If we didn't emit
the "SET search_path" then the DROP FUNCTION could fail because
"complex" might not be in the default search path.

The fact that schema ss might not exist is one of the scenarios that
we need to qualify the primary name in the DROP to protect against.
It's possible say that "complex" would get mis-resolved as some other
type "complex" in some other schema, but it doesn't matter since the
qualified function name will surely not match anything else.

What I think we ought to do is just reset currSchema once, after the
DROP phase is completed, whether or not any schemas were dropped.
This will be considerably more bulletproof in partial-restore
situations.

Will go fix.

            regards, tom lane

pgsql-patches by date:

Previous
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: Fixes for MONEY type using locale
Next
From: Bruce Momjian
Date:
Subject: Re: Problem with pg_dump -n schemaname