Re: Avoiding upgrade backlash

Поиск
Список
Период
Сортировка
От Stefan Kaltenbrunner
Тема Re: Avoiding upgrade backlash
Дата
Msg-id 473976DE.4040404@kaltenbrunner.cc
обсуждение исходный текст
Ответ на Re: Avoiding upgrade backlash  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Avoiding upgrade backlash
Список pgsql-advocacy
Peter Eisentraut wrote:
> Am Montag, 12. November 2007 schrieb Josh Berkus:
>> I'm thinking that we need to warn everyone about:
>> 1) They need to use 8.3's pg_dump, not the old version, to upgrade (this is
>> always true but now doing it wrong will break a lot more users).
>
> What difference would pg_dump make?

well the current problem is that either way pg_dump can generate dumps
that are not restorable without modification on 8.3 (like say one that
contains a VIEW that does a INTEGER = TEXT comparision which 8.3 will
refuse to create) even if dumped with 8.3.

>
>> 2) They need to check for bugs
>
> What bugs?

queries that depend on implict casts "just working" - most of those are
actually bug or maybe sloppy coding on the application side but it is
imho by FAR the most incompatible behaviour change we have done in the
last few releases.
I guess that the largest amount of these are TEXT/INTEGER casts and the
kind of app that will probably hit most are the ones that are
misbehaving anyway (think EAV style stuff) - but it is a incompatible
change nevertheless.

>
>> 3) If Robert gets his type-cast backport package together, the location of
>> that.
>
> Well, if you want to undo the changes, you don't need a backport package; you
> can just change the cast's definition.

well the point here is that we ought to be more open about the impact of
the change and i think that the release notes need to mention that (and
maybe also an example on how to change/re-add the casts)


Stefan

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Avoiding upgrade backlash
Следующее
От: Ned Lilly
Дата:
Сообщение: high concurrent-user case studies?