I just got rid of the contrib/intarray duplicates of <@ and @>,
as we discussed here:
http://archives.postgresql.org/message-id/17021.1234474...@sss.pgh.pa.us
While I was testing this I realized that I wasn't getting quite the same
answers :-(. In particular, it seems that the core operators consider
an empty array to be contained in anything else, while intarray will
only return true for two nonempty arrays.
I would just go change that, except that the *real* problem is it means
GIN index searches behave differently from the operators themselves.
Using intarray's regression database,
contrib_regression=# select * from test__int where a <@ array[1,2];
a
-------
{1,1}
(1 row)
contrib_regression=# drop index text_idx;
DROP INDEX
contrib_regression=# select * from test__int where a <@ array[1,2];
a
-------
{}
{}
{}
{}
{}
{}
{}
{}
{}
{1,1}
(10 rows)
>From what I understand of GIN's internal workings, this is unfixable
because there is nothing to make an index entry on when looking at
an empty array. Unless you know of a trick to get around that,
we've got a problem here.
[ pokes around ... ] Oh dear, it doesn't work with intarray's
GIST opclasses either.
Do we have to document these operators as being not quite real
containment?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
