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 <tgl@sss.pgh.pa.us> wrote:
> "Nikolay Samokhvalov" <samokhvalov@gmail.com> 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 majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>