Here's a fun one: in 7.3 or CVS tip, try
regression=# create domain tint as int;
CREATE DOMAIN
regression=# select 1::tint > (-1);
?column?
----------
t
(1 row)
regression=# select 1::tint > (-1)::tint;
?column?
----------
f
(1 row)
How's that again? Well, when you dig into it you find that the second
case is invoking the OID greater-than operator (oidgt), which does
unsigned comparison. Why is it picking oidgt and not int4gt,
considering that the domain is based on int4? Well, the problem is that
the domain type is considered binary-compatible with both int4 and oid;
there isn't any stronger connection to the base type than there is to
any other type that's binary-compatible with the domain. So
oper_select_candidate gets down to its third tiebreaker, preferred-type
status ... and guess what, OID is a preferred type in its category while
int4 is not preferred in its category.
I suspect that the most workable fix for this is to reduce all the input
typeids to base types before we start the operator or function type
resolution routines. However, this would completely destroy any hope of
making domain-specific operators.
(I'm also reminded once again that I don't like the preferred-type
heuristics. They're too likely to produce surprising choices.)
A different line of attack would be to modify the operator/function
resolution rules to take account of domain relationships explicitly,
making the binding of domain to base type stronger than mere binary
equivalence. But I'm not clear how that might work.
Any ideas?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
