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

Reply via email to