Thanks guys, I had a feeling this was the case, but wasn't sure. The one-version pg_dump looks like a winner.
Regards Stefan ##START## => Rod Taylor <[EMAIL PROTECTED]> writes: => >> What I did next, is put a trigger on pg_attribute that should, in theory, => >> on insert and update, fire up a function that will increment a version => => > System tables do not use the same process for row insertion / updates as => > the rest of the system. You're trigger will rarely be fired. => => s/rarely/never/. We do not support triggers on system catalogs. The => system should have done its best to prevent you from creating one ... => I suppose you had to hack around with a "postgres -O" standalone backend? => => Returning to the original problem, it seems to me that comparing "pg_dump => -s" output is a reasonable way to proceed. The problem of inconsistent => output format across pg_dump versions is a red herring --- just use a => single pg_dump version (the one for your newest server) for all the => dumps. Recent pg_dump versions still talk to older servers, back to 7.0 => or thereabouts. => => regards, tom lane =>
pgp00000.pgp
Description: PGP signature
