Postgres Professional
   

Re: Avoiding upgrade backlash

From: Stefan Kaltenbrunner
Subject: Re: Avoiding upgrade backlash
Date: ,
Msg-id: 473976DE.4040404@kaltenbrunner.cc
(view: Whole thread, Raw)
In response to: Re: Avoiding upgrade backlash  (Peter Eisentraut)
Responses: Re: Avoiding upgrade backlash  (Bernd Helmle)
List: pgsql-advocacy

Tree view

Avoiding upgrade backlash  (Josh Berkus, )
 Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
 Re: Avoiding upgrade backlash  (Andrew Sullivan, )
  Re: Avoiding upgrade backlash  (Gregory Stark, )
   Re: Avoiding upgrade backlash  (Bruce Momjian, )
    Re: Avoiding upgrade backlash  (Andrew Sullivan, )
 Re: Avoiding upgrade backlash  (Peter Eisentraut, )
  Re: Avoiding upgrade backlash  (Stefan Kaltenbrunner, )
   Re: Avoiding upgrade backlash  (Bernd Helmle, )
  Re: Avoiding upgrade backlash  (Josh Berkus, )
   Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
    Re: [DOCS] Avoiding upgrade backlash  ("Joshua D. Drake", )
  Re: [DOCS] Avoiding upgrade backlash  (Tom Lane, )
 Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
  Re: Avoiding upgrade backlash  (Alvaro Herrera <-ip.org>, )
   Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
    Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
     Re: Avoiding upgrade backlash  (Peter Eisentraut, )
      Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
       Re: Avoiding upgrade backlash  (Peter Eisentraut, )
        Re: Avoiding upgrade backlash  ("Leif B. Kristensen", )
     Re: Avoiding upgrade backlash  (Greg Smith, )
    Re: Avoiding upgrade backlash  (Jon Sime, ) 
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: Josh Berkus
Date:
Subject: Re: high concurrent-user case studies?
Next:
From: Josh Berkus
Date:
Subject: Re: Avoiding upgrade backlash