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 по дате отправления: