Re: minor annoyance - search_path not reset in/after dump/restore

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: minor annoyance - search_path not reset in/after dump/restore
Дата
Msg-id CAKFQuwZtAN6_GH70G2Waj__chHqcc2ST_e1RwU6LVTmaeGzhzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: minor annoyance - search_path not reset in/after dump/restore  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: minor annoyance - search_path not reset in/after dump/restore  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-bugs
On Tuesday, January 23, 2018, Bruce Momjian <bruce@momjian.us> wrote:
The attached patch adds a RESET ALL to the end of the text dump to cause
a reset of all GUC variables.  Does this make sense to folks?  It would
only be applied to head, so it would only appear in PG 11. 

I'm inclined to take the position that if you are going to do something like this you should decide how to proceed when the restore completes.  Adding \c or RESET ALL immediately after that \i is straight-forward enough and at least in the \c case you'd get the effects of any ALTER DATABASE SET commands in the dump.  Now, usually I would place the \i itself in a file and not type it interactively...

While I cannot imagine anyone depending on the current behavior it does encourage one to reconnect to the loaded database regardless of how the restore happened.

David J.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: minor annoyance - search_path not reset in/after dump/restore
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15026: Deadlock using GIST index