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.
0001-v01-Implement-INTERFACE-access-method.patch
Description: Binary data