Jim Nasby <jim.na...@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 the commit message gives me pause:
> "Change the operator search algorithms to look for appropriate btree or hash > index opclasses, instead of assuming operators named '<' 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers