Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> For the GIN indexes, we have 2 methods for building the index and 3
> others to search it to solve the query. You're proposing that the 2
> former methods would be in the opfamily and the 3 later in the opclass.
Actually the other way around. An opclass is the subset of an opfamily
that is tightly bound to an index. The "build" methods have to be
associatable with an index, so they're part of the index's opclass.
The "query" methods could be loose in the opfamily.
> So we would want the planner to know that in the GIN case an index built
> with any opclass of a given opfamily can help answer a query that would
> need any opclass of the opfamily. Right?
The planner's not the problem here --- what's missing is the rule for
the index AM to look up the right support functions to call at runtime.
The trick is to associate the proper query support methods with any
given query operator (which'd also be loose in the family, probably).
The existing schema for pg_amop and pg_amproc is built on the assumption
that the amoplefttype/amoprighttype are sufficient for making this
association; but that seems to fall down if we would like to allow
contrib modules to add new query operators that coincidentally take the
same input types as an existing opfamily member.
regards, tom lane
