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=kT+qVWKp4xhcYJXDdW40n8QQjE/Sk5ip3fqnVkFADeY6xMkrzKRQZrrpqnSwC2qCz/
	4bH1ZIAzOv4BYPaEKEedzK0hwFkkGPDnGP17hs5kGKuHEcCCY72DqdTC83CremDa7ip5
	tkEEGpHYN0+wlTH6xQZjTHInRPUm2jidKHilc=
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>
	<0E628919-9700-47B7-9436-41CEB09DC94F@gmail.com>
	<9887.1288389232@sss.pgh.pa.us>
In-Reply-To: <9887.1288389232@sss.pgh.pa.us>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <4CC661F3-5686-4A46-BF58-547601CB59B3@gmail.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	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 20:24:54 -0400
To: Tom Lane <tgl@sss.pgh.pa.us>

On Oct 29, 2010, at 5:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Yeah, I think we're going to have to live with it, at least for 8.4.  One=
 could make an argument that 9.0 is new enough we could get away with a smal=
l behavior change to avoid a large amount of user confusion.  But that may b=
e a self-serving argument based on wanting to tamp down the bug reports rath=
er than a wisely considered policy decision...  so I'm not sure I quite buy i=
t.
>=20
> Well, tamping down the bug reports is good from the users' point of view
> too.
>=20
> The argument for not changing it in the back branches is that there
> might be someone depending on the 8.4/9.0 behavior.  However, that seems
> moderately unlikely.  Also, if we wait, that just increases the chances
> that someone will come to depend on it, and then have a problem when
> they migrate to 9.1.  I think the "risk of breakage" argument has a lot
> more force when considering long-standing behaviors than things we just
> recently introduced.

I'm not entirely sure that a behavior we released well over a year ago can b=
e considered "just recently introduced"...

...Robert=