Bruce Momjian <br...@momjian.us> writes: > Tom Lane wrote: >> I think you're just creating useless work for yourself by imagining that >> pg_migrator is backend-version-independent. In fact, I was thinking >> about proposing that we pull it in as a contrib module. Because so much >> of what it does is tied to details of backend and pg_dump behavior, it's >> just a pipe dream to think that developing it as a separate project is >> helpful.
> Well, I do think it will work for 8.3 to 8.4 ,and 8.4 to 8.5 --- I test > that regularly and I have not seen any failures in that regard. If we > move it into /contrib, I will make sure fixes get backpatched. FYI, a > typical test is: > 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers