operators and indices?

Alex Pilosov <alex@pilosoft.com> writes:

I've noticed that all custom operators or inet type (such as <<, <<=, etc)
cannot use an index, even though it is possible to define such an
operation on an index, for ex:
X << Y can be translated to "X >= network(Y) && X <= broadcast(Y)" (or so)

You could possibly kluge that in the same way that LIKE is handled,
see match_special_index_operator() and friends. But before we extend
that kluge to too many operators, we ought to think about inventing
a table-driven implementation instead of hardwired code. I have no
idea what one might look like though :-( ... there's not a lot of
regularity visible in the cases at hand.

According to docs, postgres has hard-coded the ops which match index types
(such as btree for <,>,=, etc and rtree for @, etc).

It's not hardwired, at least not from the point of view of the mainframe
backend. A given index AM defines the semantics of the operators it can
deal with, and then the pg_amop etc. tables show which operators fill
which roles for each supported datatype.

If you can come up with a useful generalization of that inet property
for other datatypes, we could think about extending the set of operator
roles for btree. But as long as we're dealing with one-of-a-kind
special cases for particular datatypes, I'm not sure there's any better
answer than hardwired code...

regards, tom lane