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 24630.1516396044@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>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What do people think of just removing this DROP DATABASE restriction?
>> Arguably, superusers should know better than to drop template1 anyway.
>> Maybe we should replace it with a hard-wired check against dropping
>> template0 (matched by name) just to stave off the worst-case scenario.

> I think it's a little scary.  The tail might be wagging the dog at this point.

True, and having to make assumptions about which server version we're
restoring to is not very nice either.

After further reflection I've found a way to do this on the pg_dump
end that's not as ugly as I feared -- no uglier than most of the other
hacks there, anyway.  So nevermind ...

            regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)