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 | 21574.1516379296@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 between pg_dump and pg_dumpall
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Well, we could say that the properties of template1 and postgres >>>> are only restored if you use --clean. >>> True. Would that be a POLA violation, do you think? >> It seems a bit non-orthogonal. Also, while your point that people >> expect "merge" behavior from pg_dump is certainly true, I'm not >> convinced that anybody would be relying on that for pg_dumpall. > [ assorted examples ] > Still, it's worth thinking over these kinds of > scenarios, I think. People do a lot of ugly things in the real world > that we as developers would never do, mostly to work around the > problems we fail to foresee. Unless someone has a better idea, I'll go with the semantics stated above: DB-level properties of the two standard databases are only transferred to pg_dumpall's target cluster if you authorize dropping their old contents by saying --clean. (pg_upgrade, of course, will do exactly that.) regards, tom lane
В списке pgsql-hackers по дате отправления: