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 D2B9F2A20670C84685EF7D183F2949E2373D5F@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>)
Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db  (John R Pierce <pierce@hogranch.com>)
Список pgsql-bugs
Thank you for your quick reply (my first post/bug report).

When changeing my database partly to partitions, I introduced two =
schemas to separate current and archive data.

According to Postgres DOC chapter 5.8.3 it is generally not advisable to =
use schema qualified names for any objects but to use search_path =
instead.

In my opinion this encouraged naming of objects without explicit schema =
is semantically part of the application (e.g. functions) even when not =
written by words.

When setting the search_path altered for the database it becomes =
semantically a part of the database and the application. This implies it =
should be dumped with the content of the database to preserve the =
consistency of the application.

The same applies to cases with only one schema with no standard name =
(when public becomes myapplication).

My point is the logical consistency of what consists a database and how =
to transport all information in one container (a dump).

Even the syntax (ALTER DATABASE xxxdb SET SEARCH PATH) suggests this to =
be part of the database and not of a session or the cluster.

These are my 2 cents as being relatively new to PostgreSQL.

Thanks

Hans Buschmann

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re:
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db