Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id CFE35476456; Tue, 12 Nov 2002 13:45:17 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id AEFD14761EA; Tue, 12 Nov 2002 13:45:10 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id gACIinhR010375; Tue, 12 Nov 2002 13:44:49 -0500 (EST) To: "Josh Berkus" Cc: pogden@claresco.com, pgsql-sql@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Inconsistent or incomplete behavior obverse in where In-reply-to: References: Comments: In-reply-to "Josh Berkus" message dated "Tue, 12 Nov 2002 10:23:02 -0800" Date: Tue, 12 Nov 2002 13:44:49 -0500 Message-ID: <10374.1037126689@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200211/196 X-Sequence-Number: 10338 "Josh Berkus" writes: > Now, that's interesting. Why would defining a "numeric = float" have > broken "numeric = integer"? There's no reason I can think of. The problem probably is that the parser now finds two possible interpretations that look equally good to it, so it can't choose. It could coerce the integer constant to numeric (and use numeric=numeric) or to float (and use the added numeric=float operator), and there's no rule that can break the tie. In 7.3 and 7.4 we are actually going in the direction of removing cross-data-type operators, not adding them, because they tend to create too many options for the parser to choose from. regards, tom lane