Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db - Mailing list pgsql-bugs

From Hans Buschmann
Subject Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Date
Msg-id D2B9F2A20670C84685EF7D183F2949E2373D62@gigant.nidsa.net
Whole thread Raw
In response to BUG #14192: pg_dump/pg_restore omit setting search_path in restored db  (buschmann@nidsa.net)
Responses Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db  ("David G. Johnston" <david.g.johnston@gmail.com>)
List 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.

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Segmentation fault with postgres -C external_pid_file
Next
From: Michael Paquier
Date:
Subject: Re: BUG #13907: Restore materialized view throw permission denied