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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Debian readline/libedit breakage
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Careful PL/Perl Release Not Required