Re: A question on GIN indexes and arrays

Sorry, as a final follow up here, another option (should anyone run into
this and want to keep the intarray extension) is to create the index using
the gin__int_ops operator:

CREATE INDEX ON sets USING GIN(obj_id gin__int_ops);

On Sun, Aug 20, 2017 at 4:22 PM, Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
wrote:

> YES!
>
> \dx yields intarray was installed (back in the 9.1 days, maybe) and that
> was clobbering the @> operator.
>
> Looking into the implications of removing intarray now that we're at 9.6,
> seems harmless, but will do my due diligence.
>
> Thanks Jeff.
>
>
>
> On Sun, Aug 20, 2017 at 3:15 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
>> On Sun, Aug 20, 2017 at 1:28 PM, Wells Oliver <wells(dot)oliver(at)gmail(dot)com>
>> wrote:
>>
>>>
>>> Why is this happening and what can I do to get my GIN indexes working?
>>> Thanks!
>>>
>>>
>> What extensions do you have installed in each database? I bet one of
>> them (like intarray) redefines @> for one of your databases.
>>
>> Try fully qualifying the operator. OPERATOR(pg_catalog.@>)
>>
>> Cheers,
>>
>> Jeff
>>
>
>
>
> --
> Wells Oliver
> wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>
>

--
Wells Oliver
wells(dot)oliver(at)gmail(dot)com <wellsoliver(at)gmail(dot)com>