Re: pg_dump and schema names
От | Bruce Momjian |
---|---|
Тема | Re: pg_dump and schema names |
Дата | |
Msg-id | 20130809164441.GB3353@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_dump and schema names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump and schema names
|
Список | pgsql-hackers |
On Fri, Aug 9, 2013 at 01:48:43AM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > pg_dump goes to great lengths not to hard-code the schema name into > > commands like CREATE TABLE, instead setting the search_path before > > creating the table; these commands: > > > CREATE SCHEMA xx; > > CREATE TABLE xx.test(x int); > > > generates this output: > > > SET search_path = xx, pg_catalog; > > CREATE TABLE test ( > > x integer > > ); > > > If you dump a schema and want to reload it into another schema, you > > should only need to update that one search_path line. However, later in > > the dump file, we hardcode the schema name for setting the object owner: > > > ALTER TABLE xx.test OWNER TO postgres; > > > Could we use search_path here to avoid the schema designation? > > Perhaps, but that's not likely to reduce the number of places you have to > edit, unless your dump is only one schema anyway. > > The practical difficulties involved can be seen by reading the comments > and code for _getObjectDescription(). Yes, I looked at that. Seems _getObjectDescription() is only called from _printTocEntry(), and that function has a call to _selectOutputSchema() at the top, so we already know we have search_path set to the proper schema. The attached patch removes the unnecessary schema qualification for ALTER OWNER, and the attached dump file show a two-schema dump that restores just fine. Basically, if we are going to use search_path to avoid schema specification, we should do it in ALTER OWNER too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: