2011/1/3 Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
