Re: ALTER EXTENSION UPGRADE, v3
От | marcin mank |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | AANLkTimvXuHt6ef+tu5wfpNBJWPdt-3z91q+_j_=3j5+@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER EXTENSION UPGRADE, v3
|
Список | pgsql-hackers |
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Kääriäinen Anssi <anssi.kaariainen@thl.fi> writes: >> This has the side effect that you can also have downgrade scripts. I >> don't know if this is designed or just coincidental, so thought it >> would be worth mentioning. >> 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? > Say we have 20 versions, with up- and downgrade scripts between consecutive versions, and a fast path from 5 to 20. if we are at version 6, it would go 6->5->20. if 6->5 drops a table, we`re in trouble. Greetings Marcin Mańk
В списке pgsql-hackers по дате отправления: