Re: [HACKERS] Re: type coersion (was OR clause status)

> I think I have found part of the cause.  We have duplicate type
> conversion functions, and the parser is choosing the one that is not
> in the access method tables.

I don't think so for this case; I got stuck on this for awhile too. It
seems that "oidint4" is an actual data type, so has an "oidint4eq"
comparison function. The parser/planner/optimizer is finding the correct
functions, which are "oideqint4" and "int4eqoid".

Don't know what "oidint4" actually does or how it's used. Confusing...

                       - Tom

---------------------------------------------------------------------------
>
> test=> select * from pg_operator where oid = 1137;
>
oprname|oprowner|oprprec|oprkind|oprisleft|oprcanhash|oprleft|oprright|oprresult|oprcom|oprnegate|oprlsortop|oprrsortop|oprcode
>  |oprrest|oprjoin
>
-------+--------+-------+-------+---------+----------+-------+--------+---------+------+---------+----------+----------+---------+-------+---------
> =      |     139|      0|b      |t        |t         |     26|      23|
>      16|  1136|        0|         0|         0|oideqint4|eqsel
> |eqjoinsel (1 row)
>
> test=> select * from pg_operator where oid = 932;
>
oprname|oprowner|oprprec|oprkind|oprisleft|oprcanhash|oprleft|oprright|oprresult|oprcom|oprnegate|oprlsortop|oprrsortop|oprcode
>  |oprrest |oprjoin
>
-------+--------+-------+-------+---------+----------+-------+--------+---------+------+---------+----------+----------+---------+--------+------------
> =      |     139|      0|b      |t        |f         |    910|     910|
>      16|   932|      935|         0|         0|oidint4eq|intltsel|intltjoinsel (1 row)