David Fetter 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.
Odds are that the patch submitters will not understand enough to know
how to modify pg_migrator, but just knowing something broke is usually
enough for the hackers group to find a fix.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
