Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Andrew Dunstan wrote: > >> I thought the idea was just to support migration from version N to > >> version N+1. > > > Oh, I will also support many older _source_ versions, like 8.3 and 8.4. > > Really? Nobody else has bought into that, and it's not only pg_migrator > that would have to go out of its way to support such cases. You're > talking about cross-multi-version compatibility of on-disk formats too.
Well, it works. I have a test suite that I run regularly. Because of the way pg_migrator works it is pretty painless to support multiple _source_ major versions. The binary format issue is relevant, but until we have a way to remove the old binary format, I don't see much value in supporting just one source version. For example, we don't have any system now to remove the HEAP_MOVED_OFF and HEAP_MOVED_IN heap bits so effectively major versions have to support them forever. Now, if we develop a system where a version would _remove_ the old data format, we would then specify that pg_migrator can only migrate _from_ one major version, and you would have to run a script to remove the old data format. For example, migrating from 9.0 to 9.2 would requiring migrating from 9.0 to 9.1 with pg_migrator, updating the data pages to 9.1 format, then using pg_migrator again to migrate from 9.1 to 9.2, but of course, we are not there yet. My guess is that when that happens we would just document/enforce it in pg_migrator, but I don't see why we would arbitrarily restrict pg_migrator at this time. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
