I wrote:
> I wonder whether we couldn't fix this better by insisting that these
> operations depend on default btree opclasses instead of looking up
> "=" by name. Upthread I whined that this wouldn't work for comparisons
> of nonidentical datatypes, but could we insist for cross-type cases that
> both types have default btree opclasses belonging to the same opfamily?
I thought a bit more about this, and that idea isn't going to work, at
least not by itself. Right now you can do, eg, "integer IS DISTINCT
FROM numeric", and it works, but the way it works is that the integer
is promoted to numeric and we use the "numeric = numeric" operator.
int and numeric do not have an opfamily in common, so this case would
fail with the rule above.
A reasonable way to handle that sort of case is to do select_common_type
(ie, UNION-like type promotion) and then insist that the common type have
a default btree opclass.
However, the common-opfamily approach seems like a better idea when it
works, since it would avoid a runtime type coercion in cases where there
is a suitable cross-type comparison operator. So what I now suggest is:
1. If the two inputs are of types that have default btree opclasses in
the same opfamily, and that opfamily has an equality operator that
accepts these input types, use that operator.
2. Otherwise, do select_common_type(), and see if the common type has
a default btree opclass. If so, use that opclass's equality operator
after coercing both inputs to the common type.
3. If neither of those work, fail.
regards, tom lane
