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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: minor annoyance - search_path not reset in/after dump/restore
Дата
Msg-id 20180124144711.GH17109@momjian.us
обсуждение исходный текст
Ответ на Re: minor annoyance - search_path not reset in/after dump/restore  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-bugs
On Tue, Jan 23, 2018 at 08:45:24PM -0700, David G. Johnston wrote:
> 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.

OK, agreed.  A pg_dumpall restore will leave you in a different
database.  I will assume this item is closed.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


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

Предыдущее
От: Patrik Uytterhoeven
Дата:
Сообщение: postgis package broken in postgresql 9.3 repo
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Fwd: Error about save extracted data