There was a discussion back here: http://archives.postgresql.org/pgsql-bugs/2008-01/msg00189.php that came to the conclusion that cross-type operators are a bad idea if they don't come in complete sets: if you don't have an exact match to the input types, and there are multiple possible candidates, then the system doesn't know what to pick.
I looked through pg_operator just now, and found that we seem to be okay as far as comparison operators go, but we do have issues for basic arithmetic operators. Specifically, these cross-type operators aren't part of complete sets: OID | OPERATOR 548 | % (smallint,integer) 549 | % (integer,smallint) 690 | * (bigint,integer) 544 | * (smallint,integer) 694 | * (integer,bigint) 545 | * (integer,smallint) 688 | + (bigint,integer) 552 | + (smallint,integer) 692 | + (integer,bigint) 553 | + (integer,smallint) 689 | - (bigint,integer) 556 | - (smallint,integer) 693 | - (integer,bigint) 557 | - (integer,smallint) 691 | / (bigint,integer) 546 | / (smallint,integer) 695 | / (integer,bigint) 547 | / (integer,smallint) We could either remove all of these, or fill in the sets. Removal would mean that cross-type cases would get implemented as a coercion function feeding a single-data-type operator, which would be marginally slower to execute (I'm not sure it would be significant). What I'm inclined to do is remove the two % operators, which don't seem likely to be performance-critical, and fill in the missing int2-vs-int8 cases for the four basic arithmetic operators. But I could be talked into just nuking everything listed above (and their underlying functions of course). Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers