On Tue, Dec 3, 2013 at 8:43 AM, Dimitri Fontaine <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
