Re: Problem with pg_dump -n schemaname

Bruce Momjian <bruce(at)momjian(dot)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