Re: Extending opfamilies for GIN indexes

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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