Re: ALTER EXTENSION UPGRADE, v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ALTER EXTENSION UPGRADE, v3
Date: 2011-02-10 20:58:54
Message-ID: 4254.1297371534@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-02-10 21:11:38 Re: ALTER EXTENSION UPGRADE, v3
Previous Message Robert Haas 2011-02-10 20:58:03 Re: ALTER EXTENSION UPGRADE, v3