The short-term workaround for Rusty is probably to create his GIN
index using the intarray-provided gin__int_ops opclass. But it
Right
seems to me that we ought to get rid of intarray's @ and @ operators
and have the module depend on the core anyarray operators, just as we
have already done
On Fri, Feb 13, 2009 at 04:12:53PM +0300, Teodor Sigaev wrote:
The short-term workaround for Rusty is probably to create his GIN
index using the intarray-provided gin__int_ops opclass. But it
Right
seems to me that we ought to get rid of intarray's @ and @ operators
and have the module
Teodor Sigaev teo...@sigaev.ru writes:
seems to me that we ought to get rid of intarray's @ and @ operators
and have the module depend on the core anyarray operators, just as we
have already done for = and . Comments?
Agree, will do. Although built-in anyarray operators have ~N^2 behaviour
Rusty Conover rcono...@infogears.com writes:
The gist__int_ops is the default operator class for integer[] arrays,
as shown at:
http://www.postgresql.org/docs/current/static/intarray.html
Ah, so you have contrib/intarray installed.
[ pokes at it... ] Seems like what we have here is another
