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
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 |