From: | "Hans Buschmann" <buschmann(at)nidsa(dot)net> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | "John R Pierce" <pierce(at)hogranch(dot)com>, <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db |
Date: | 2016-06-16 07:39:35 |
Message-ID: | D2B9F2A20670C84685EF7D183F2949E2373D62@gigant.nidsa.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I understand the differences between cluster and database and pg_dumpall and pg_dump.
In my opinion a pg_dump of a database should pack all informations of the application (the database) in the dumpfile in one container, to be able to restore it full functional at a different place.
Because the search_path is a crucial information for the application to work correctly (like any other object inside the database) it should be packed into this container called pg_dump dumpfile.
This should be independent of the current implementation, where we store the search_path in a cluster record: The informatation belongs semantically to the content of the database, even if it is stored elsewhere.
My concern with promoting this suggestion is to avoid trouble in emergency cases, logical consistency, intuitive usage of pg_dump and smooth experience for non-expert people.
Hans B.
From | Date | Subject | |
---|---|---|---|
Next Message | jeremy.rumerio | 2016-06-16 08:52:01 | BUG #14196: Processes terminated with exception 0xFFFFFFFF |
Previous Message | Michael Paquier | 2016-06-16 07:28:45 | Re: BUG #13907: Restore materialized view throw permission denied |