Daniel Farina <drfar...@acm.org> writes:
> Well, why not? I was in the middle of writing it. But I'm open to
> other approaches, the real motivating issue could be stated simply as:
> "pg_dump --clean should produce output that can be run on empty, full
> or partially-full databases in a transaction without a non-zero error
> code"
[ shrug... ] I'm less than convinced that that's an important goal.
If you don't know what it is you're overwriting, maybe you should
stop and think what you're doing, instead of expecting pg_dump to
silently stomp on portions of whatever you already have.
What you're proposing would maybe be useful for overwriting a database
that contains portions of what is in the source database, but what's
the use of that? You could just as well dropdb and start fresh. The
interesting case here is where the target db has *more* objects than
are in the dump, and I really doubt that there is any self-consistent
behavior that pg_dump can automatically provide for such cases. It
can't drop objects it doesn't know about, and it also has no hope of
ensuring that their relationships to the replaced objects remain
consistent. Silently wiping out FKs, for instance, seems like a pretty
bad idea.
So, basically, I've never seen any fully credible use case for pg_dump
--clean, and this proposal does nothing to fix that. I don't see the
argument for putting a large amount of work down that rathole.
Especially not if the only benefit you get out of it is not looking
at error messages. In most cases you'd *better* study those error
messages, to see what manual cleanup you're going to need to undertake.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
