Writing new restriction selectivity estimation functions is far beyond the scope of this chapter, but fortunately you can usually just use one of the system's standard estimators for many of your own operators. You can frequently get away with using either eqsel or neqsel for operators that have very high or very low selectivity, even if they aren't really equality or inequality. For example, the approximate-equality geometric operators use eqsel on the assumption that they'll usually only match a small fraction of the entries in a table. You can use scalarltsel and scalargtsel for comparisons on datatypes that have some sensible means of being converted into numeric scalars for range comparisons. If you do not do this, things will still work, but the optimizer's estimates won't be as good as they could be.
JOIN clauses only make sense for binary operators that return boolean.
The assumption underlying hash join is that the join operator can only return TRUE for pairs of left and right values that hash to the same hash code. But if the optimizer chose to use a different kind of join, all the pairs that the equality operator says are equal will be found. We don't want that kind of inconsistency, so we don't mark interval equality as hashable. There are also machine-dependent ways in which a hash join might fail to do the right thing. SORT2 The SORT clauses, if present, tell the system that it is permissible to use the merge join method for a join based on the current operator.