Re: Overloaded && operator from intarray module prevents index usage.

Andrew Gierth schrieb am 28.02.2019 um 10:29:
> [intarray woes]
> 
>  Thomas> Is this expected behaviour? Is this caused by the Postgres core
>  Thomas> (e.g. the optimizer to taking the opclass into account) or is
>  Thomas> it a "problem" in the way the intarray module defines its
>  Thomas> operators?
> 
> It's basically a conflict between intarray (which is historically older)
> and the built-in array indexing support.
> 
> The reason it happens is that the operator resolution logic matches an
> (integer[] && integer[]) operator in preference to (anyarray && anyarray)
> regardless of their relative position on the search_path. This
> resolution happens before anything is known about any indexes that might
> be applicable. Then later, at planning time, an index is chosen based on
> the operator, not the reverse.

That makes sense, thanks.