There are a number of changes we'd probably like to make to the way
things work in Postgres. This thread is not about discussing what
those are, just to say that requirements exist and have been discussed
in various threads over time.
The constraint on such changes is that we've decided that we must have
an upgrade path from release to release.
So I'd like to make a formal suggestion of a plan for how we cope with this:
1. Implement online upgrade in 9.4 via the various facilities we have
in-progress. That looks completely possible.
2. Name the next release after that 10.0 (would have been 9.5). We
declare now that
a) 10.0 will support on-line upgrade from 9.4 (only)
b) various major incompatibilities will be introduced in 10.0 - the
change in release number will indicate to everybody that is the case
c) agree that there will be no pg_upgrade patch from 9.4 to 10.0, so
that we will not be constrained by that
This plan doesn't presume any particular change. Each change would
need to be discussed on a separate thread, with a separate case for
each. All I'm suggesting is that we have a coherent plan for the
timing of such changes, so we can bundle them together into one
release.
By doing this now we give ourselves lots of time to plan changes that
will see us good for another decade. If we don't do this, then we
simply risk losing the iniative by continuing to support legacy
formats and approaches.
--Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
