Tom,
Can you please suggest a good practice how to propagate such DB
settings into dumps?
I also suffer from this: my DB currently have 5 schemas and
application strongly depends on the search_path. I cannot dump whole
cluster, I need only 1 specific database. At this moment I use ugly
solution and store search_path setting as per-user settings in my
secondary databases.
Solution of Nikolay, being improved for backward compatibility
(additional switch for pg_dump to include alter database statements
with these settings into sql dump generated) would fit me perfectly.
But unfortunately you're not constructive in your critics here and do
not propose a way to solve the problem, only saying that this (very
useful and awaited option!) is ugly. With approach like this the
community will wait for the solution for ages.
:-(
On 10/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> What is the reason to not include database settings (like search_path)
> to database dump created with "pg_dump -C"?
Duplication of code and functionality with pg_dumpall. I'd want to see
some thought about how to resolve that, not just a quick copy-some-code-
from-pg_dumpall-into-pg_dump. You also need to explain why this issue
should be treated differently from users and groups ... a dump won't
restore correctly without that supporting context either.
I have no objection to rethinking the division of labor between the two
programs, but let's end up with something that's cleaner not uglier.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
