Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id EC3E91337B71 for ; Fri, 29 Oct 2010 18:54:00 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 55105-07 for ; Fri, 29 Oct 2010 21:53:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 879021336705 for ; Fri, 29 Oct 2010 18:53:53 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o9TLrqLJ009888; Fri, 29 Oct 2010 17:53:52 -0400 (EDT) To: Robert Haas cc: Kevin Grittner , Jon Nelson , "" Subject: Re: [PERFORM] typoed column name, but postgres didn't grump In-reply-to: <0E628919-9700-47B7-9436-41CEB09DC94F@gmail.com> References: <4480.1288374498@sss.pgh.pa.us> <4CCACE6E0200002500036F95@gw.wicourts.gov> <6240.1288379246@sss.pgh.pa.us> <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> Comments: In-reply-to Robert Haas message dated "Fri, 29 Oct 2010 17:48:59 -0400" Date: Fri, 29 Oct 2010 17:53:52 -0400 Message-ID: <9887.1288389232@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/274 X-Sequence-Number: 28564 Robert Haas 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 small behavior 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 than a wisely considered policy decision... so I'm not sure I quite buy it. Well, tamping down the bug reports is good from the users' point of view too. 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. regards, tom lane