Re: ALTER EXTENSION UPGRADE, v3

Dimitri Fontaine <dimitri@2ndquadrant.fr>

From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kääriäinen Anssi <anssi.kaariainen@thl.fi>, Dimitri Fontaine <dimitri@2ndQuadrant.fr>, "David E. Wheeler" <david@kineticode.com>, Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>, "pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2011-02-11T20:49:17Z
Lists: pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:
>> The worst case is that if you are upgrading from 1.2 to 2.0 the path
>> is 1.2 -> 1.1 -> 2.0, even if there exists a path 1.2 -> 1.8 -> 1.9 ->
>> 2.0. This could potentially result in data loss, if the downgrade
>> drops some columns or something like that.
>
> Hmm.  That seems like it would require a rather pathological collection
> of upgrade scripts.  In particular why would you have a one-step upgrade
> from 1.1 to 2.0 but no short path from 1.2?

I think it just mean that we have to provide a function for extension
authors to check and validate their upgrade chains.  We have to have a
way to check that without having to replay all the possible and
supported upgrade situations provided in the script, because it's a pain
to defend against cycles made up by the system that you didn't intend to
support.

Maybe something like:
=# SELECT * FROM pg_available_extension_upgrades('foo');
 installed | available |          chain           
-----------+-----------+--------------------------
 1.2       | 2.0       | 1.2 -> 1.1 -> 2.0
 1.2       | 1.9       | 1.2 -> 1.8 -> 1.9 -> 2.0
 1.2       | 1.8       | 1.2 -> 1.8
 1.2       | 1.1       | 1.2 -> 1.1
(4 rows)

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support