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