Re: Removing pg_migrator limitations

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.

regards, tom lane