2011/1/3 Tom Lane <tgl@sss.pgh.pa.us>:
> pg_dump from dumping objects in a consistent order ... and once you do
> that, you don't need this patch.
> Yeah, that's exactly it. I can think of some possible uses for
> splitting up pg_dump output, but frankly "to ease diff-ing" is not
> one of them. For that problem, it's nothing but a crude kluge that
> only sort-of helps. If we're to get anywhere on this, we need a
> better-defined problem statement that everyone can agree is worth
> solving and is well solved with this particular approach.
The problem statement is only partly diffing, I think the two major
other problems with one-single-giant-schema-file is:
1. Automatically version controlling your production database schema
using a file based approach is not possible.
Splitting the schema would mean it's very simple to setup a cronjob
which automatically commits the schema changes every night. You would
be able to follow the changes by simply looking at the vcs log,
instead of grepping the log files and trying to figure out what
changed.
2. Splitting is a single option which reduces the need for any other
imaginable exclude/include options, such as "only export these
functions" or "do not export views" etc. Tables are of course the most
common thing you want to include/exclude in a dump, but there are
quite a lot of different object types, however, no single object type
is "important enough" to motivate a new pg_dump option to allow a
exclusion/inclusion option, but I think the sum of the need for such
an option for all object types is greather than the extra complexity
introduced by a patch consisting of only a few lines of code.
--
Best regards,
Joel Jacobson
Glue Finance