| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: minor annoyance - search_path not reset in/after dump/restore |
| Date: | 2018-01-24 03:45:24 |
| Message-ID: | CAKFQuwZtAN6_GH70G2Waj__chHqcc2ST_e1RwU6LVTmaeGzhzQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tuesday, January 23, 2018, Bruce Momjian <bruce(at)momjian(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2018-01-24 04:47:06 | BUG #15026: Deadlock using GIST index |
| Previous Message | Bruce Momjian | 2018-01-24 02:51:30 | Re: minor annoyance - search_path not reset in/after dump/restore |