Re: Removing pg_migrator limitations

On Sun, Dec 20, 2009 at 2:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> There's a reason to clutter, eg, pg_dump with multiple version support.
>>> I don't see the argument for doing so with pg_migrator.  Separate source
>>> code branches seem like a much better idea.
>
>> I guess we have to look at the specific cases that come up, but ISTM
>> that a branch here amounts to a second copy of the code that has to be
>> separately maintained.  I'm having a hard time working up much
>> enthusiasm for that prospect.
>
> Well, it'd be exactly like back-patching fixes across multiple branches
> is for fixes in the core code now.  In code that hasn't changed across
> branches, that's not terribly painful.  If the code has changed, then
> you're going to have pain no matter which way you do it.
>
> But the real problem with having pg_migrator be a separate project is
> that a lot of the time "fix pg_migrator" is really going to mean "fix
> pg_dump" or even "change the backend".  We already had problems with
> version skew between pg_migrator and various 8.4 alpha/beta releases.
> That type of problem isn't likely to magically go away in the future.

I agree that pulling pg_migrator into contrib seems pretty sensible.
What I want to make sure we're on the same page about is which
versions the 8.5 pg_migrator will allow you to upgrade from and to. I
think we should at least support 8.3 -> 8.5 and 8.4 -> 8.5. If you're
saying we don't need to support 8.3 -> 8.4 any more once 8.5 comes
out, I'm probably OK with that, but perhaps we should try to get a few
more opinions before setting that policy in stone.

...Robert