Re: Removing pg_migrator limitations
От | Robert Haas |
---|---|
Тема | Re: Removing pg_migrator limitations |
Дата | |
Msg-id | 603c8f070912201058g10ed6ce7m74ad54216f2a3d13@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing pg_migrator limitations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Removing pg_migrator limitations
|
Список | 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
В списке pgsql-hackers по дате отправления: