Re: ALTER EXTENSION UPGRADE, v3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER EXTENSION UPGRADE, v3
Date
Msg-id 4254.1297371534@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER EXTENSION UPGRADE, v3  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ALTER EXTENSION UPGRADE, v3
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The design as I sketched it didn't need to make any assumptions at all
>> about the meaning of the version identifiers. �But if you were willing
>> to assume that the identifiers are comparable/sortable by some rule,

> You don't need them to be sortable.  You just need them to be
> comparable, and equality seems like a plenty good enough comparison
> rule.  You can compute the shortest chain of upgrade scripts that can
> take you from the current version to the target version.

Hmm.  The problem with that is that once there are large numbers of
intermediate versions, the number of potential paths grows
exponentially.  I was envisioning an algorithm like this:

1.  Scan directory for upgrade scripts with oldversion = version we
have, and take the one with largest newversion <= version we want.

2.  Apply this script (or more likely, just remember it until we've
verified there is a chain leading to version we want).

3.  If now the version is not what we want, return to step 1.

I don't see an equally efficient method if we only have equality.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3
Next
From: Dimitri Fontaine
Date:
Subject: Re: ALTER EXTENSION UPGRADE, v3