Tom Lane wrote:
> Magnus Hagander <mag...@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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to