Re: Extending opfamilies for GIN indexes

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

AFAICS that means integrating contrib/intarray into core. Independently
of whether that's a good idea or not, PG is supposed to be an extensible
system, so it would be nice to have a solution that supported add-on
extensions.

The subtext here is that GIN, unlike the other index AMs, uses a
representation that seems pretty amenable to supporting a wide variety
of query types with a single index. contrib/intarray's "query_int"
operators are not at all like the subset-inclusion-testing operators
that the core opclass supports, and it's not very hard to think of
additional cases that could be of interest to somebody (example: find
all arrays that contain some/all entries within a given integer range).
I think we're going to come up against similar situations over and over
until we find a solution.

regards, tom lane