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)