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

> 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.

FOLLOWUP:

This may fix our int4/oid problem, but I don't think it addresses the
more common problems like int2/int4. I can't see how that would work
with just additions to pg_amop.

Yes, we have the int2eqint4 function, but how does that work in an
index. Actually, it was my understanding that the new conversion code
was going to get rid of the int2eqint4 style functions, and replace them
with conversions.

Thomas, perhaps a quick summary of the logic behind your parser
conversion changes would help.

--
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)