Robert Haas wrote: > > My guess is that when that happens we would just document/enforce it > > in > > pg_migrator, but I don't see why we would arbitrarily restrict > > pg_migrator at this time. > > Yeah. It's not uncommon to want to upgrade by more than one release at > a time, and I haven't heard any reason why we should arbitrarily > refuse to support that. Of course we may need to do that eventually > for some specific reason, but it seems like we should only consider > imposing such a restriction in the face of a tangible need.
Yea, we will need it one day, and if pg_migrator was more tied to system table changes and such, it would be smart to do it now, but if you look at the C code you will see that most of the effort is related to compatibility with the _target_ major version, not the _source_ major version, and by definition, the source major version never changes as we release new major versions. (Remember, pg_dump already does the heavy lifting of moving our database schema to the new major version.) A lot of understanding pg_migrator is understanding the source/target matrix of compatibility --- something we as a community have not thought about very much at this level. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers