"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
