Tom Lane wrote:
> 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 unclassifiable stuff
>
> 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.
Because the 8.5 is alpha anyway, and because pg_migrator works with
current CVS, let's just say it works and wait for someone to report a
problem.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
