Re: Extending opfamilies for GIN indexes

On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Maybe this is a dumb question, but why not just put whatever stuff
intarray[] adds directly into the core opfamily?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company