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

  1. Move handling of database properties from pg_dumpall into pg_dump.

  2. Allow pg_dumpall to dump roles w/o user passwords

  3. Fix pg_dumpall to work for databases flagged as read-only.