Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 79CD32E106F;
	Tue, 13 Nov 2007 06:03:55 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 08504-09; Tue, 13 Nov 2007 06:03:47 -0400 (AST)
Received: from cronos.madness.at (madness.at [217.196.146.217])
	by postgresql.org (Postfix) with ESMTP id 519452E096D;
	Tue, 13 Nov 2007 06:03:52 -0400 (AST)
Received: from congw.dc1.conova.com ([217.196.145.250] helo=[192.168.1.61])
	by cronos.madness.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.63) (envelope-from <stefan@kaltenbrunner.cc>)
	id 1IrscQ-00011x-Ne; Tue, 13 Nov 2007 11:03:46 +0100
Message-ID: <473976DE.4040404@kaltenbrunner.cc>
Date: Tue, 13 Nov 2007 11:05:18 +0100
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
User-Agent: Icedove 1.5.0.14pre (X11/20071018)
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: pgsql-advocacy@postgresql.org,  josh@agliodbs.com,
	pgsql-docs@postgresql.org
Subject: Re: Avoiding upgrade backlash
References: <200711121442.31233.josh@agliodbs.com>
	<200711131045.04878.peter_e@gmx.net>
In-Reply-To: <200711131045.04878.peter_e@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200711/62
X-Sequence-Number: 12879

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