Rusty Conover <rconover@xxxxxxxxxxxxx> writes: > The gist__int_ops is the default operator class for integer[] arrays, > as shown at: > http://www.postgresql.org/docs/current/static/intarray.html Ah, so you have contrib/intarray installed. [ pokes at it... ] Seems like what we have here is another iteration of this ancient bug: http://archives.postgresql.org/pgsql-committers/2004-01/msg00073.php to wit, contrib/intarray is defining its own @> and <@ operators that conflict with those since added to the core. In the case Rusty is showing, the @> gets resolved as intarray's @> (because that's an exact match, where the core provides anyarray @> anyarray) and then this operator is NOT a member of the core-provided GIN opclass for integer arrays. The short-term workaround for Rusty is probably to create his GIN index using the intarray-provided gin__int_ops opclass. But it seems to me that we ought to get rid of intarray's @> and <@ operators and have the module depend on the core anyarray operators, just as we have already done for = and <>. Comments? regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
