On Tue, Dec 3, 2013 at 8:43 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> What Jeff is proposing is to simplify that down and have PostgreSQL auto
> discover the upgrade cycle when the version asked for isn't directly
> available with a creation script.
>
> We would keep the behavior depicted here, just in a fully automated way.
>
> Working on a separate patch for that, then.
I like the idea of making it automatic, but it won't work in all
cases. For example, suppose someone ships 1.0, 1.0--1.2, 1.1, and
1.1--1.2. Since versions aren't intrinsically ordered, the system has
no way of knowing whether it's preferable to run 1.0 and then 1.0--1.2
or instead run 1.1 and then 1.1--1.2. So I think we will need either
to introduce a way of ordering version numbers (which Tom has
previously opposed) or some concept like your default_full_version.
In more normal cases, however, the system can (and probably should)
figure out what was intended by choosing the *shortest* path to get to
the intended version. For example, if someone ships 1.0, 1.0--1.1,
1.1, and 1.1--1.2, the system should choose to run 1.1 and then
1.1--1.2, not 1.0 and then 1.0--1.1 and then 1.1--1.2. But that can
be automatic: only if there are two paths of equal length (as in the
example in the previous paragraph) do we need help from the user to
figure out what to do.
We should also consider the possibility of a user trying to
deliberately install and older release. For example, if the user has
1.0, 1.0--1.1, 1.1, 1.1--1.2, and 1.2--1.0 (a downgrade script) with
default_full_version = 1.2, an attempt to install 1.0 should run just
the 1.0 script, NOT 1.2 and then 1.2--1.0.
Putting all that together, I'm inclined to suggest that what we really
need is a LIST of version numbers, rather than just one. If there one
path to the version we're installing is shorter than any other, we
choose that, period. If there are multiple paths of equal length, we
break the tie by choosing which version number appears first in the
aforementioned list. If that still doesn't break the tie, either
because none of the starting points are mentioned in that list or
because there are multiple equal-length paths starting in the same
place, we give up and emit an error.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company