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.oli...@gmail.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.ja...@gmail.com> wrote: > >> On Sun, Aug 20, 2017 at 1:28 PM, Wells Oliver <wells.oli...@gmail.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.oli...@gmail.com <wellsoli...@gmail.com> > -- Wells Oliver wells.oli...@gmail.com <wellsoli...@gmail.com>