On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
