On Tue, 2013-12-03 at 10:23 -0500, Robert Haas wrote: > 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.
Why do we need help from the user? Just pick a path. For an extension update, I understand why someone wouldn't want to accidentally downgrade 5 versions (dropping all of their dependent objects) before updating to the latest. But this doesn't apply to creation. And it just seems really awkward to document, and it's a constant maintenance burden on extension authors to specify their upgrade paths every time they release a new version. > 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. That seems like extreme overkill, and still doesn't give users full control over upgrade paths. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers