Re: minor annoyance - search_path not reset in/after dump/restore - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: minor annoyance - search_path not reset in/after dump/restore
Date
Msg-id CAKFQuwZtAN6_GH70G2Waj__chHqcc2ST_e1RwU6LVTmaeGzhzQ@mail.gmail.com
Whole thread Raw
In response to Re: minor annoyance - search_path not reset in/after dump/restore  (Bruce Momjian <bruce@momjian.us>)
Responses Re: minor annoyance - search_path not reset in/after dump/restore
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: minor annoyance - search_path not reset in/after dump/restore
Next
From: PG Bug reporting form
Date:
Subject: BUG #15026: Deadlock using GIST index