> In future we could have, for instance, LSM or in-memory B-tree or
> other index AM, which could use existing B-tree or hash opclasses.
This would be easily possible with my patch:
CREATE ACCESS METHOD inmemorybtree
TYPE INDEX HANDLER imbthandler
IMPLEMENTS (ordering);
> But even now, we could use this decoupling to get rid of ugly
> btree_gist and btree_gin. And also solve the extensibility problem
> here. If an extension provides datatype with B-tree opclass, we
> currently can't directly use it with GiST and GIN. So, in order to
> provide B-tree-like indexing for GiST and GIN, an extension needs to
> explicitly define GiST and GIN B-tree-like opclasses.
This would also be possible if we move btree_gist and btree_gin
support functions inside gist and gin access methods. The access
method support functions get the operator family. They can find which
access method this operator family belongs to, and call the
appropriate functions if it is "ordering".