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
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 |