On Wed, Dec 4, 2013 at 3:39 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> 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.
I suppose. But suppose we have 1.0, 1.1, 1.0--1.2, and 1.1--1.2.
Suppose further that 1.1 drops some interfaces present in 1.0, and 1.2
adds new stuff. If the system chooses to run 1.0 and then 1.0--1.2,
it'll create all the deprecated interfaces and then drop them again.
Now maybe that won't cause any problems, but I bet it will. For
example, consider hstore again. If we eventually disallow => as an
operator altogether, the 1.0 script won't even run any more.
Of course that doesn't matter for core because we've removed it
entirely from our repository and don't ship it any more, but an
out-of-core extension might well keep around more old scripts than we
do, to make it easier to use the same bundle with multiple server
versions. Imagine, for example, that 1.0 only works on 9.4 or earlier
and 1.2 only works on releases 9.2 or later. The extension author
wants to keep the 1.0 script around for the benefit of people who
haven't upgraded, so that they can still install the older version
that works there; but he also need the 1.1 base version to be
preferred to the 1.0 base version, else installation of 1.2 on 10.0+
will fail completely. My experience with software upgrades is that
cases like this, and even weirder things, happen pretty routinely, so
I think more control is good.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company