Robert Haas wrote:
> On Mon, Aug 3, 2009 at 2:07 PM, David Fetter<david@fetter.org> wrote:
> > On Mon, Aug 03, 2009 at 12:19:40PM -0400, Tom Lane wrote:
> >> David Fetter <david@fetter.org> writes:
> >> > On Mon, Aug 03, 2009 at 11:32:48AM -0400, Tom Lane wrote:
> >> >> And I doubt we'd bother generating pg_migrator builds that work
> >> >> for pairs of alpha releases.
> >>
> >> > That's an interesting idea. ?Shouldn't pg_migrator be mandated to
> >> > work for *any* catversion bump?
> >>
> >> Oh, are you volunteering to make that happen? ?That code is going to
> >> be ugly enough just dealing with pairs of major releases ...
> >
> > With all due respect, if pg_migrator does not function in such a way
> > as to have data-driven composable changes, it's going to bang us up in
> > the long haul much worse than not branching alphas ever could.
> >
> > We require that people supply docs with their changes, and it is
> > totally unreasonable to let them send in catalog changes which do not
> > include need migration changes. ?That's how it works in every other
> > RDBMS outfit that has changes on disk, and we do not need to be the
> > exception.
> >
> > If pg_migrator doesn't have this ability, we need to refactor it until
> > it does, or go with something that can.
>
> I don't disagree with this, but we don't have anyone to do the work
> atm, even if it were exactly clear what to do, which it isn't. What
> we could do, though, is try to figure out whether it will work between
> 8.4.0 and 8.5alpha1.
I just tested this and it works fine. In fact it even does 8.3 to
8.5devel, with no pg_migrator changes needed.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
