Andrew Dunstan <andrew@dunslane.net> writes:
Well, the other issue is how many canned breakup schemes we are going to
support. If this particular one is of sufficiently general usefulness
then I have no objection. But when you can produce it trivially from the
output of "pg_dump -s", the need to hardcode it hardly seems pressing.
FWIW, I am in favor of providing a way to break up the dump output like
this, I was merely objecting to the vocabulary ;-). We have certainly
seen tons of people burnt by the performance problems inherent in
separate-data-and-schema restores, and splitting the dump into three
parts instead of two seems like it would fix that.
But I also like Alvaro's comment that this should be on the restore side
not so much the dump side. If you do two or three successive pg_dump
runs to make your dump then you run a nontrivial risk of not getting
consistent dumps. My advice to people would be to do *one* full
"pg_dump -Fc" and then extract three scripts out of that.
The question then is whether it's worth providing the extraction
functionality in a more canned, user-friendly form than "here, hack up
the -L output with this perl script". I'd vote yes.
regards, tom lane
I greatly appreciate the comments here and am glad that my initial idea
has support. This thread highlights to me the difference between the
"hey there's a good idea there despite the fact that's he's obviously
not a veteran software developer" culture that the PostgreSQL community
has instead of the "he is obviously not a veteran software developer so
what on Earth could he have to offer us" responses I've had from
various other open source projects.