Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db

From: "Hans Buschmann" <buschmann(at)nidsa(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Date: 2016-06-15 15:49:58
Message-ID: D2B9F2A20670C84685EF7D183F2949E2373D5F@gigant.nidsa.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2016-06-15 17:25:59 Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Previous Message John R Pierce 2016-06-15 15:48:35 Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db