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
|
Список | 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 по дате отправления: