Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>,
Vaishnavi Prabakaran <vaishnaviprabakaran@gmail.com>,
Michael Paquier <michael.paquier@gmail.com>,
Thomas Munro <thomas.munro@enterprisedb.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Andreas Karlsson <andreas@proxel.se>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-01-19T16:28:16Z
Lists: 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
Commits
-
Move handling of database properties from pg_dumpall into pg_dump.
- b3f8401205af 11.0 landed
-
Allow pg_dumpall to dump roles w/o user passwords
- 9a83d56b38c8 10.0 cited
-
Fix pg_dumpall to work for databases flagged as read-only.
- 4bd371f6f886 9.4.0 cited