I think we can benefit from higher level operator classes which can
support multiple index implementations. This is achievable by
introducing another type of access method. Here is my idea in SQL:
CREATE ACCESS METHOD ordering
TYPE INTERFACE HANDLER ordering_ifam_handler;
CREATE ACCESS METHOD btree
TYPE INDEX HANDLER bthandler
IMPLEMENTS (ordering);
CREATE OPERATOR CLASS btree_int_ops
FOR TYPE int USING ordering AS
FUNCTION 1 btint4cmp(int, int),
FUNCTION 3 =(int, int);
This can make it easier to develop both new index access methods and
data types. The extensions can provide them without depending on each
other.
The initial implementation is attached. I wrote it only to ask for
feedback. I am happy to work on the missing pieces if the community
supports the idea.
I suggest the initial version to come with 2 new access methods in the
new type: hashing and ordering. We can use those in the functions
that are currently searching for the hash and btree operator classes.
Later, I want to work on developing another access method for
containment. It can support high level operator classes with only SQL
callable functions. GiST, SP-GiST, and BRIN can implement this. We
can allow the new implementations together with the existing ones.