Re: pg_migrator to /contrib in a later 9.0 beta

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