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

> #0 op_class (opno=1137, opclass=427, amopid=403) at lsyscache.c:58
> oideqint4 oid_ops btree_am_oid
>
>
> and it returns false because there is no access operator for oid_ops and
> btree_am_oid that matches oideqint4.
>
> The fundamental problem is that index scans are made to compare columns
> all of the same type. That is how indexes are built and traversed.
> Now, we want to bring in a constant of another type, and have it use an
> index.
>
> Sounds like if we add the proper pg_am functions for binary
> compatability, the optimizer should then use the proper indexes.

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.

---------------------------------------------------------------------------

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)

t

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)