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  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Segmentation fault with postgres -C external_pid_file
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #13907: Restore materialized view throw permission denied