| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Vaishnavi Prabakaran <vaishnaviprabakaran(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |
| Date: | 2018-01-19 21:07:24 |
| Message-ID: | 24630.1516396044@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-01-19 21:27:03 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Previous Message | Robert Haas | 2018-01-19 20:43:39 | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |