Re: Avoiding upgrade backlash - Mailing list pgsql-advocacy

From Stefan Kaltenbrunner
Subject Re: Avoiding upgrade backlash
Date
Msg-id 473976DE.4040404@kaltenbrunner.cc
Whole thread Raw
In response to Re: Avoiding upgrade backlash  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Avoiding upgrade backlash
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Avoiding upgrade backlash
Next
From: Ned Lilly
Date:
Subject: high concurrent-user case studies?