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

From David G. Johnston
Subject Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Date
Msg-id CAKFQuwZO8JUr1=a8ZCWqwN+gyc6rrcsmxReYJJTCMrcTA8cKCw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db  ("Hans Buschmann" <buschmann@nidsa.net>)
List pgsql-bugs
On Wed, Jun 15, 2016 at 11:49 AM, Hans Buschmann <buschmann@nidsa.net>
wrote:

>
> 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 i=
s
> semantically part of the application (e.g. functions) even when not writt=
en
> 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 (whe=
n
> public becomes myapplication).
>
> My point is the logical consistency of what consists a database and how t=
o
> transport all information in one container (a dump).
>
> Even the syntax (ALTER DATABASE xxxdb SET SEARCH PATH) suggests this to b=
e
> part of the database and not of a session or the cluster.
>
> These are my 2 cents as being relatively new to PostgreSQL.
>
I suspect most people would agree with this sentiment.  But the status-quo,
while less than ideal, allows for the end result to be realized, if
imperfectly, and thus the motivation to donate ones time to improving it is
not that great.


=E2=80=8BThe underlying point is that users are global - but there is no "g=
lobal
shell" to operate from so every command has to be executed while within a
specific database.  The specific mapping you are making when you do "ALTER
DATABASE" has an optional user component (which if not specified simply
means all users) and so it too ends up being global=E2=80=8B.

David J.

pgsql-bugs by date:

Previous
From: "Hans Buschmann"
Date:
Subject: Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Next
From: John R Pierce
Date:
Subject: Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db