On Tue, Jun 22, 2021 at 8:06 PM Tom Lane <tgl@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