>>>>> "Thomas" == Thomas Kellerer <spam_eater@xxxxxxx> 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)
