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

Reply via email to