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