Re: Decouple operator classes from index access methods

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
> 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.

I do not really understand what the point of that is?

To the extent that operator classes have any meaning at all apart
from the associated index AMs, ISTM it's that they embody specific
well-known semantics, as btree and hash opclasses do for sorting
and hashing respectively. I'm not clear on what a multi-AM
opclass notion would do for us.

> 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.

regards, tom lane