Re: Fwd: pg_dump VS alter database ... set search_path ...

On 10/9/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Duplication of code and functionality with pg_dumpall.

Well, then "-C" option of pg_dump can be considered as duplication of
pg_dumpall's functionality too, right?

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

"-C" option is useful in cases like mine. Example: in a PG cluster of
100 databases there is one database containing 10 schemes; this
database is being dumped every night and restored on 3 separate
machines, where some operations are then being executed). pg_dumpall
is not a solution in this case. Moreover, playing with "ALTER USER ...
SET search_path TO ..." may not the best solution too - there may be
different users sets on different hosts, and, what is more important,
if I (developing my app) add new schema to that database, I should run
<number of hosts> * <number of roles> ALTERs, this is not good.

When I write "ALTER DATABASE ... SET ..." I expect that corresponding
*database's* property will be modified. When I choose "-C" option of
pg_dump I expect that "CREATE DATABASE" with all its properties (in
ALTER stmts) will be printed. I think it's not a question of "division
of labor between the two programs".

As for "users and groups" - I do not understand why you are mentioning
it. I'm talking about "-C" option, and complain that it doesn't allow
me to dump/restore the database with its properties. I suppose,
users/roles shouldn't be involved in this discussion.

Maybe my understanding is wrong - I'll be glad to hear why.

--
Best regards,
Nikolay