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.oliver@xxxxxxxxx> 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.janes@xxxxxxxxx> wrote:On Sun, Aug 20, 2017 at 1:28 PM, Wells Oliver <wells.oliver@xxxxxxxxx> 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,JeffWells Oliver
wells.oliver@xxxxxxxxx
Wells Oliver
wells.oliver@xxxxxxxxx
wells.oliver@xxxxxxxxx