Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
Date
Msg-id CA+TgmoaWvj6q8WfUjq3N3_wXQ77eWLUsbH8o-HNydSes-vj=+w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
List pgsql-hackers
On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

True.  Would that be a POLA violation, do you think?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Next
From: Jörg Westheide
Date:
Subject: [PATCH] make check with Apple's SIP enabled