Thread: Type resolution for operators

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

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/

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
anexplicit 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