Today it occurred to me that we could look in pg_opclass for a default btree opclass for the datatype. If we find one, then the Equal and Less members of the opclass are the operators we want. (If we don't find one, we could try for a default hash opclass, which would give us Equal, but not Less, for a few additional datatypes.) This seems like a much cleaner approach for two reasons: the opclass structure declares directly that the operators have the semantics we are looking for, and the search is not dependent on schema visibility. (We only allow one default opclass per datatype/AM, so the result would be unique.)
This sounds like a big improvement.
In several of these cases, equality_oper is actually wrong --- box_eq for example compares areas, which is not what one would consider the normal equality behavior for boxes. The only ones that really ought to be found are the ones for TID, MONEY, and ACLITEM. I'm not particularly concerned about losing the ability to group by any of those datatypes, but if anyone is, we could talk about forcing an initdb to add the necessary comparison operators.
I'd go for the initdb.
Joe
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
