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
