Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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.
> I have to admit I'm a bit unsold on the approach as well. It seems > like you could write a short Perl script which would transform a text > format dump into the proposed format pretty easily, and if you did > that and published the script, then the next poor shmuck who had the > same problem could either use the script as-is or hack it up to meet > some slightly different set of requirements. Or maybe you'd be better > off basing such a script on the custom or tar format instead, in order > to avoid the problem of misidentifying a line beginning with --- as a > comment when it's really part of a data item. Or maybe even writing a > whole "schema diff" tool that would take two custom-format dumps as > inputs. > On the other hand, I can certainly think of times when even a pretty > dumb implementation of this would have saved me some time. The basic objection that I have to this patch is that it proposes to institutionalize a pretty dumb implementation. And, as you mentioned, once it's in there it'll be more or less set in stone because we aren't going to want to support umpteen variants. I like the idea of a postprocessing script a lot better --- it seems like it wouldn't get in the way of people making their own variants. And as you say it'd likely be pretty trivial to do. 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