Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> I'd say that array_eq (and probably _cmp) just needs to be taught to fall back to what oper() does, but this part of
thecommit message gives me pause:
> "Change the operator search algorithms to look for appropriate btree or hash index opclasses, instead of assuming
operatorsnamed '<' or '=' have the right semantics."
As it should. array_cmp is the basis for a btree opclass, therefore
it must *not* use operators that are not themselves btree operators.
Quite aside from that, we need to move even further away from having
internal system operations depend on operator-name-based lookups;
see for instance the recent complaints over stuff like IS DISTINCT FROM
failing for types whose operators aren't in the search path.
It's arguable that the typcache code should be taught to look for
binary-compatible opclasses if it can't find one directly for the
specified type. I'm not sure offhand what rules we'd need to make
to ensure such a search would yield deterministic results, though.
Another possibility is that we might be able to extend the "text_ops"
btree operator family to include an opclass entry for varchar, rather than
relying on binary compatibility to find the text opclass. But that would
also require some careful thought to understand what the relaxed
invariants should be for the opfamily structure as a whole. We don't want
to add more actual operators, for fear of creating ambiguous-operator
lookup failures.
regards, tom lane