I've committed changes to parse_oper.c to enable fallback to string type
when argument(s) are of UNKNOWN type. This is the same code (verbatim)
as I recently added for function resolution.

An obvious example is for

  select '1' = '01';

which used to throw an error and which now resolves to two text strings
(and returns 'false'). To force these to be handled as integers, prefix
one with the "int" type specifier:

  select int '1' = '01';

which, btw, returns 'true'.

Regression tests pass without change (which I guess means that we don't
have good coverage there, either :/

                      - Thomas

Tue, 07 Nov 2000 17:15:59 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Type resolution for operators
Thomas Lockhart writes:

> (and returns 'false'). To force these to be handled as integers, prefix
> one with the "int" type specifier:
> 
>   select int '1' = '01';
> 
> which, btw, returns 'true'.

Uh, how can an integer be equal to a character value?  Where did the type
system go?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Wed, 8 Nov 2000 17:51:38 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: Type resolution for operators
Peter Eisentraut <peter_e@gmx.net> writes:
> Thomas Lockhart writes:
>> select int '1' = '01';
>> which, btw, returns 'true'.

> Uh, how can an integer be equal to a character value?  Where did the type
> system go?

Nowhere.  This is the same behavior as that statement had in 7.0 (and
many versions before, I believe): given "int4-constant operator
unknown-constant", the unknown constant is preferentially resolved to
int4.

Now if you say

select int '1' = text '01';

you should and do get

ERROR:  Unable to identify an operator '=' for types 'int4' and 'text'
        You will have to retype this query using an explicit cast

But this change is *not* to rip out the concept of unknown-type
constants entirely, only to fall back to treating them as text
*after* all else fails.

			regards, tom lane

Wed, 08 Nov 2000 12:08:42 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Type resolution for operators 