>>>>> "Thomas" == Thomas Kellerer <spam_eater@gmx.net> writes:
[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.
My own recommendation for most cases is to never install intarray on the
search path, and invoke its functions via explicit qualification or wrap
them in your own functions.
--
Andrew (irc:RhodiumToad)