Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com