Re: Extending opfamilies for GIN indexes

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

I had understood your proposal to change that for GIN. Thinking again
now with keeping opfamily and opclass as they are now: an opclass is the
code we run to build and scan the index, an opfamily is a way to use the
same index data and code in more contexts than strictly covered by an
opclass.

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

Well the opfamily machinery allows to give query support to any index
whose opclass is in the family. That is, the same set of operators are
covered by more than one opclass.

What we want to add is more than one set of operators can find data
support in more than one "index kind". But you still want to run
specific search code here. So it seems to me we shouldn't attack the
problem at the operator left and right type level, but rather model that
we need another level of flexibility, separating somewhat the index data
building and maintaining from the code that's used to access it.

The example that we're working from seem to be covered if we are able to
instruct PostgreSQL than a set of opclass'es are "binary coercible", I
think that's the term here.

Then the idea would be to have PostgreSQL able to figure out that a
given index can be used with any binary coercible opclass, rather than
only the one used to maintain it. What do you think?

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support