Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > 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.
>
> I wasn't suggesting that we should arbitrarily refuse to support cases
> that would work otherwise. What I *was* saying is that the community
> has not bought into doing any extra work to support
> cross-multiple-version migrations, and I don't think it will do so.
> It would be a mistake to give users the impression that such cases can
> be expected to work in future. In particular we should not provide a
> documentation table that is set up to give the impression that
> multi-version upgrades are going to be supported. The docs should be
> written to make it clear that one-version-at-a-time is the normal case,
> and any cases where you can take a shortcut should be documented as
> exceptions.
Well, that is going to make the documentation more complicated than it
already is. Why mention a process in 9.0 that no one needs to use? I
am not writing the docs for some hypothetical release, but for 9.0.
When we have some restriction, we can document that.
My guess is that 9.2 will be able to upgrade from 8.3, 8.4, 9.0, and
9.1, but that going to 9.5 will require you to go to 9.2 first, run some
script, then upgrade to 9.5; again all hypothetical. I think we can
require people using pg_migrator to read matching documentation for that
major version of pg_migrator, and pg_migrator will enforce any
restrictions we come up with in the future. For example, I assume there
will be some major version of Postgres where pg_migrator will not work
at all.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com