On Feb 12, 2009, at 2:29 PM, Tom Lane wrote:
Rusty Conover <rcono...@infogears.com> 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?
Hi Tom,
For the record using the GIN opclass does resolve the problem for me.
The indexes are now seeing usage.
Thanks for the help,
Rusty
--
Rusty Conover
rcono...@infogears.com
InfoGears Inc / GearBuyer.com / FootwearBuyer.com
http://www.infogears.com
http://www.gearbuyer.com
http://www.footwearbuyer.com
