On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <tgl@sss.pgh.pa.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.
Yeah, I'm just wondering if it's worth the effort, especially in view
of a rather large patch queue we seem to have outstanding at the
moment.
> 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.
Interesting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
