Emre Hasegeli <e...@hasegeli.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