Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Robert Haas wrote:
> >> I don't think it's going
> >> to be practical to retain all the migration code for every pair of
> >> versions forever,
>
> > I thought the idea was just to support migration from version N to
> > version N+1.
>
> Yeah. I think trying to do more than that is just going to make things
> messy. For example, we added features to pg_dump and the core server
> since 8.4 to help pg_migrator do its thing. Trying to make the same
> pg_migrator code support cases with and without those features available
> is going to complicate the code, not to mention the documentation,
> enormously.
As a summary, let me list the migrations pg_migrator supports:
8.3 -> 8.48.4 -> 9.08.3 -> 9.0
Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
doesn't have access to the features we added in Postgres 9.0.
Tom is right that the code could be cleaned up if we removed 8.3 -> 8.4,
but more importantly the documentation would be clearer.
> To the extent that future bug fixes are relevant to multiple versions
> of pg_migrator, we could just apply them to multiple branches, same as
> we manage such fixes for the core code. I don't see that trying to
> have a single version of pg_migrator is going to make things easier
> anywhere.
Yea, that is probably right. We can enforce in pg_migrator that you can
only migrate to the matching major version you are using in /contrib.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com