Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
