Re: [HACKERS] Inconsistent or incomplete behavior obverse in where

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: pogden(at)claresco(dot)com, pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Inconsistent or incomplete behavior obverse in where
Date: 2002-11-12 18:44:49
Message-ID: 10374.1037126689@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

"Josh Berkus" <josh(at)agliodbs(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2002-11-12 18:49:18 Re: RC1?
Previous Message Tom Lane 2002-11-12 18:34:47 Re: Inconsistent or incomplete behavior obverse in where clause

Browse pgsql-sql by date

  From Date Subject
Next Message Rajesh Kumar Mallah. 2002-11-12 18:48:18 Re: [SQL] Output of function into a file
Previous Message Tom Lane 2002-11-12 18:34:47 Re: Inconsistent or incomplete behavior obverse in where clause