Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall |
| Дата | |
| Msg-id | 24630.1516396044@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall (Robert Haas <robertmhaas@gmail.com>) |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера