Re: ALTER EXTENSION UPGRADE, v3

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: ALTER EXTENSION UPGRADE, v3
Дата
Msg-id m2vd0q47qq.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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.01.2       | 1.9       | 1.2
->1.8 -> 1.9 -> 2.01.2       | 1.8       | 1.2 -> 1.81.2       | 1.1       | 1.2 -> 1.1
 
(4 rows)

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER EXTENSION UPGRADE, v3
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: review: FDW API