Re: Extending opfamilies for GIN indexes

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Oh, wait a minute: there's a bad restriction there, namely that a
>> contrib module could only add "loose" operators that had different
>> declared input types from the ones known to the core opclass.

> I would have though that such contrib would then need to offer their own
> opfamily and opclasses, and users would have to use the specific opclass
> manually like they do e.g. for text_pattern_ops.  Can't it work that way?

I think you missed the point: right now, to use both the core and
intarray operators on an integer[] column, you have to create *two*
GIN indexes, which will have exactly identical contents.  I'm looking
for a way to let intarray extend the core opfamily definition so that
one index can serve.
        regards, tom lane