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.
...Robert