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-19T14:45:41Z
Lists: 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
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