Joel Jacobson <j...@gluefinance.com> writes: > 2010/12/28 Tom Lane <t...@sss.pgh.pa.us> >> That has at least as many failure modes as the other representation.
> I don't follow, what do you mean with "failure modes"? The oid in the > filename? I suggested to use a sequence instead but you didn't comment on > that. Are there any other failure modes which could cause a diff -r between > two different databases to break? AFAIK the primary failure modes for diff'ing text dumps are (1) randomly different ordering of objects from one dump to another. Your initial proposal would avoid that problem as long as the object OIDs didn't change, but since it falls down completely across a dump and reload, or delete and recreate, I can't really see that it's a step forward. Using a sequence number generated by pg_dump doesn't change this at all --- the sequence would be just as unpredictable. (2) randomly different ordering of rows within a table. Your patch didn't address that, unless I misunderstood quite a bit. I think the correct fix for (1) is to improve pg_dump's method for sorting objects. It's not that bad now, but it does have issues with random ordering of similarly-named objects. IIRC Peter Eisentraut proposed something for this last winter but it seemed a mite too ugly, and he got beaten down to just this: commit 1acc06a1f4ae752793d2199d8d462a6708c8acc2 Author: Peter Eisentraut <pete...@gmx.net> Date: Mon Feb 15 19:59:47 2010 +0000 When sorting functions in pg_dump, break ties (same name) by number of argum ents Maybe you can do better, but I'd suggest going back to reread the discussion that preceded that patch. > (This might be a bad idea for some other reason, but I noticed a few other > users requesting the same feature when I googled "pg_dump split".) AFAIR what those folk really wanted was a selective dump with more selectivity knobs than exist now. I don't think their lives would be improved by having to root through a twisty little maze of numbered files to find the object they wanted. 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