Re: Operator class group proposal

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I'm not sure. The problem that I'm seeing is that currently, cross-type
> comparisons go into the opclass associated with their left-hand argument
> type. Therefore, if say you want to add "tinyint" to an opclass group,
> you not only need to add an opclass for tinyint (containing tinyint vs
> tinyint as well as tinyint vs other-type operators), but you also need
> to add other-type vs tinyint operators to the *other* members of the
> group. So the notion of the classes being separate objects seems a bit
> artificial to me. I think that "if I want to make tinyint part of the
> numeric_ops index opclass, I just add the type and all these operators to
> that opclass" is at least as clear.

Hm, would we still need all the cross-data-type btree operators? Could the
planner be taught that as long as the two types belong to the same
opclassclass that it's ok to use a btree operator that requires a cast first
before being used?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com