DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	b=J0+kVD2LKg9dBnJ2Z67n7XOQ7E/YTNEk3px1zJ2x9LfRKolE2J3sAiuNbPum0RFZvw
	h8mBDTyCctAp2bAEJKLvB8yPISqSsFj9YqqYFQbv7nEp5bb4FuY88dlV8CGORAIZGXWn
	fuxIrTeJzz9ILd7x3rOeFLGKCJQ2skHN7xTQk=
References: <AANLkTimYMA8D2h4-jHK5vD032jWwig1iJmW6uF-3i=Bx@mail.gmail.com>
	<4480.1288374498@sss.pgh.pa.us>
	<4CCACE6E0200002500036F95@gw.wicourts.gov>
	<6240.1288379246@sss.pgh.pa.us>
	<AANLkTim35FrP1EyZRmnotKSw=2rq8JNVutkitn9PXwFp@mail.gmail.com>
	<4CCADE440200002500036FB2@gw.wicourts.gov>
	<4CCADE440200002500036FB2@gw.wicourts.gov>
	<8216.1288383162@sss.pgh.pa.us>
	<4CCAE6650200002500036FC3@gw.wicourts.gov>
In-Reply-To: <4CCAE6650200002500036FC3@gw.wicourts.gov>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <0E628919-9700-47B7-9436-41CEB09DC94F@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jon Nelson <jnelson+pgsql@jamponi.net>,
	"<pgsql-bugs@postgresql.org>" <pgsql-bugs@postgresql.org>
From: Robert Haas <robertmhaas@gmail.com>
Subject: Re: [PERFORM] typoed column name, but postgres didn't grump
Date: Fri, 29 Oct 2010 17:48:59 -0400
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>

On Oct 29, 2010, at 4:21 PM, "Kevin Grittner" <Kevin.Grittner@wicourts.gov> w=
rote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>>> Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> I think if I had to pick a proposal, I'd say we should disable
>>>>> #2 for the specific case of casting a composite type to
>>>>> something else.
>>=20
>>>> Well, then let's do that.  It's not the exact fix I'd pick, but
>>>> it's clearly better than nothing, so I'm willing to sign on to
>>>> it as a compromise position.
>>=20
>>> So, I'd rather scrap #2 entirely; but if that really would break
>>> much working code, +1 for ignoring it when it would cast a
>>> composite to something else.
>>=20
>> Well, assuming for the sake of argument that we have consensus on
>> fixing it like that, is this something we should just do in HEAD,
>> or should we back-patch into 8.4 and 9.0?  We'll be hearing about
>> it nigh indefinitely if we don't, but on the other hand this isn't
>> the kind of thing we like to change in released branches.
>=20
> I can't see back-patching it -- it's a behavior change.
>=20
> On the bright side, in five years after the release where it's
> removed, it will be out of support.  Problem reports caused by it
> should be tapering off before that....

Yeah, I think we're going to have to live with it, at least for 8.4.  One co=
uld make an argument that 9.0 is new enough we could get away with a small b=
ehavior change to avoid a large amount of user confusion.  But that may be a=
 self-serving argument based on wanting to tamp down the bug reports rather t=
han a wisely considered policy decision...  so I'm not sure I quite buy it.

...Robert=