Re: Removing pg_migrator limitations
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2009-12-20T18:58:56Z
Lists: pgsql-hackers
On Sun, Dec 20, 2009 at 1:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> if (GET_MAJOR_VERSION(ctx.old.pg_version) <= 803 && >> GET_MAJOR_VERSION(ctx.new.pg_version) >= 804) > > Well, yeah, you can probably make it work if you're willing to carry > enoguh version tests and alternate sets of logic in the source code. > I don't think that is a particularly good engineering approach however. > It makes things less readable and probably more buggy. Particularly > so since we are talking about some quite significant logic changes here. > > 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. ...Robert