Re: 9.2 upgrade glitch with search_path
От | Bruce Momjian |
---|---|
Тема | Re: 9.2 upgrade glitch with search_path |
Дата | |
Msg-id | 20130115210523.GB27932@momjian.us обсуждение исходный текст |
Ответ на | Re: 9.2 upgrade glitch with search_path (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 9.2 upgrade glitch with search_path
|
Список | pgsql-general |
On Sun, Jan 13, 2013 at 04:51:55PM -0500, Tom Lane wrote: > Scott Ribe <scott_ribe@elevated-dev.com> writes: > > Built & installed 9.2.3. Dumped 9.1 db (using 9.2 pg_dump IIRC). Restored. > > Database search path was not restored. Had to execute alter database ... set search_path to... > > That's a hole in the particular dump methodology you selected: > > > pg_dumpall -g -f roles.dump > > pg_dump -F c -Z 0 -v pedcard > db.dump > > pg_dump does not dump/restore database properties, only database > contents. Properties are the responsibility of pg_dumpall, which > you bypassed (for databases anyway). > > There's been some discussion of refactoring these responsibilities, > but no consensus. pg_upgrade fixed this for pg_dumpall -g --binary-upgrade by outputing the per-database settings. Isn't this a bug? Seems there is no way to get these exported without pg_dumpall non-'g' mode. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-general по дате отправления: