On Tue, Jun 22, 2021 at 8:06 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. > > Again, exactly what does that buy us, other than more complication > and overhead? > > I can see some value perhaps in letting other opclasses refer to > btree and hash opclasses rather than duplicating their entries. > But that doesn't seem to be what you're proposing here.
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. 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. >From my point of view, we can consider a decoupling patch if it will come with an ability to use B-tree opclasses directly in GiST and GIN. ------ Regards, Alexander Korotkov
