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

From Tom Lane
Subject Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Date
Msg-id 21574.1516379296@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Built-in connection pooling
Next
From: Ryan Murphy
Date:
Subject: Re: Add default role 'pg_access_server_files'