Magnus Hagander <magnus@hagander.net> writes:
> I haven't actually looked into pg_migrator enough to know how likely
> it is that it'll "just work" going alpha->alpha when there have only
> been "normal" changes? How invasive are the changes that actually
> require pg_migrator to be touched at all?
To my mind there are three categories of stuff that pg_migrator has to
do:
* catalog changes (handled by pg_dump/reload)* on-disk data layout changes (not handled yet anyway)* random weird
unclassifiablestuff
It's the third category that is the problem. An example from the 8.3 to
8.4 migration is the need to specially handle sequences because they're
not compatible on-disk. Any pair of releases you might pick is going to
have its own little quirks like that. Our intention (at least as I see
it) is to minimize pg_migrator's complexity by decreeing that any given
release of pg_migrator deals with exactly one pair of PG releases.
I don't think that works if alpha->alpha has to be supported --- in
particular, 8.5alpha1 to 8.5alpha2 might be quite different from what
will be needed later for 8.4 to 8.5, so you would end up with multiple
live branches of pg_migrator, or else a lot of spaghetti code trying to
track which actions to take for a given case.
The other little problem is who's going to do this work and when.
The alpha-release idea was sold to us on the basis of being a small
amount of incremental work: just tag an alpha release right after
CommitFest and kick it out there. If we're waiting around for someone
to produce and test a compatible pg_migrator, that's not going to be
how it works.
regards, tom lane
