pg_dump DROP commands and implicit search paths - Mailing list pgsql-hackers

From Tom Lane
Subject pg_dump DROP commands and implicit search paths
Date
Msg-id 12105.1021316288@sss.pgh.pa.us
Whole thread Raw
Responses Re: pg_dump DROP commands and implicit search paths
List pgsql-hackers
I'm working on cleaning up loose ends in pg_dump, and in particular
trying to ensure that objects in user schemas can be named the same
as system objects without conflicts.  Most of this works now, thanks
to Peter's idea about explicitly setting the search path to include
just the current target schema.  But there is a problem with pg_dump's
option to issue explicit DROP commands.  Right now, with that option
pg_dump will produce output like
set search_path = my_schema;
drop table my_table;
create table my_table (...);

This works fine unless the object name duplicates a system object;
in that case, since the effective search path is really "pg_catalog,
my_schema", the DROP will find and try to drop the system object.

I can think of two workable solutions to this:

1. Explicitly qualify target-object names in the DROP commands,
ie, we'd emit
set search_path = my_schema;
drop table my_schema.my_table;
create table my_table (...);

2. Modify the backend so that DROP has a different behavior from
other commands: it only searches the explicitly named search path
elements (and the TEMP table schema, if any).  If pg_catalog is
being searched implicitly then DROP does not look there.

Choice #1 is logically cleaner but would clutter the dump script with
many more explicit schema references than I'd like to have.  Choice #2
is awfully ugly at first glance but might prove a good idea in the long
run.  It'd certainly reduce the odds of mistakenly dropping a predefined
object.

Not sure which way to go.  Comments anyone?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joel Burton"
Date:
Subject: Re: TRUNCATE
Next
From: "C. Maj"
Date:
Subject: Re: pgaccess - the discussion is over