pg_dump DROP commands and implicit search paths

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pg_dump DROP commands and implicit search paths
Дата
Msg-id 12105.1021316288@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: pg_dump DROP commands and implicit search paths  (nconway@klamath.dyndns.org (Neil Conway))
Список 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 по дате отправления:

Предыдущее
От: "Joel Burton"
Дата:
Сообщение: Re: TRUNCATE
Следующее
От: "C. Maj"
Дата:
Сообщение: Re: pgaccess - the discussion is over