This example forwarded from pgsql-sql:
create table x (a char(20));
CREATE
create table y (b varchar(20));
CREATE
select * from x a, y b where a.a = b.b;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query
usingan explicit cast
OK so far, but:
select * from x a, y b where text(a.a) = text(b.b);
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query
usingan explicit cast
select * from x a, y b where a.a::text = b.b::text;
ERROR: Unable to identify an operator '=' for types 'bpchar' and 'varchar' You will have to retype this query
usingan explicit cast
6.5.3 and current sources behave the same.
I believe this is an artifact of a misbehavior that I've noticed before:
when the parser decides that an explicit typecast or type conversion
function is a no-op (because of binary compatibility of the types
involved), it simply throws away the conversion in toto. Seems to me
that it should relabel the subexpression as having the result type of
the requested conversion. Otherwise, subsequent processing will use
operators appropriate to the original type not the converted type,
which presumably is exactly what the user didn't want.
Thomas, any comments on this?
regards, tom lane
