Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Here is my logic. I am having trouble getting the big picture on this:
>
> Th big picture is that it doesn't work very well to assume that indexes
> only need to handle same-datatype comparisons. I think we are
> ultimately going to have to address that issue more-or-less directly.
>
> At least for btree indexes, it doesn't seem that the index mechanics
> would have too big a problem with this --- as long as you are using the
> proper comparison function, who cares whether the righthand side of the
> comparison is the same datatype as the left? It might be harder for
> other index types, but 99.9% of the problem is with btrees anyway.
> I think if we implemented it only for btrees we'd still have a usable
> solution.
>
> I'm currently digging around to see how much of the rest of the backend
> really cares about it ...
Wouldn't that logically lead to an "abstract" operator class to be
pointed to in the original indexes operator class?
In the concrete example, int8, a btree index is using int8_ops for
opcamid 403. This operator class is specifically set up with 5 operators
designed for int8 to int8 comparision. Assume we create a pseudo
operator class that only tells the operator names "<, <=, =, >= and >",
but does not already resolve them to the operators and thus the
comparision functions and allow int8_ops to be substituted with this
pseudo operator class. In the case the planner sees a type mismatch in
the comparision, and the index operator class points to our pseudo
opclass, then it could try "on the fly" to construct the operator class
if it finds cross type operators/functions for all 5 needed operators.
Not that I know much about the planner, more asking.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #