Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |
Дата | |
Msg-id | 15873.1516373141@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If we did it like that, the rationale for an actual --set-db-properties >> switch would vanish, at least so far as pg_dumpall is concerned -- we >> could just make all that behavior an integral part of --create. And >> this wouldn't need to be conditional on getting ALTER DATABASE >> CURRENT_DATABASE done. > Unfortunately, I have a feeling that --set-db-properties might not be > the only thing that would vanish. I think users are accustomed by now > to the idea that if you restore into an existing database, the > existing contents are preserved and the new stuff from the dump is > added (possibly with some errors and messiness). With this design, > the existing database contents will instead vanish, and that is > probably going to make somebody unhappy. Well, we could say that the properties of template1 and postgres are only restored if you use --clean. regards, tom lane
В списке pgsql-hackers по дате отправления: