Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Дата
Msg-id 21574.1516379296@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Built-in connection pooling
Следующее
От: Ryan Murphy
Дата:
Сообщение: Re: Add default role 'pg_access_server_files'