Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
От | Hans Buschmann |
---|---|
Тема | Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db |
Дата | |
Msg-id | D2B9F2A20670C84685EF7D183F2949E2373D62@gigant.nidsa.net обсуждение исходный текст |
Ответ на | BUG #14192: pg_dump/pg_restore omit setting search_path in restored db (buschmann@nidsa.net) |
Ответы |
Re: BUG #14192: pg_dump/pg_restore omit setting search_path in
restored db
|
Список | 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 по дате отправления: