contrib/intarray vs empty arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: contrib/intarray vs empty arrays
Date: 2009-04-05 01:11:16
Message-ID: 7706.1238893876@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I just got rid of the contrib/intarray duplicates of <@ and @>,
as we discussed here:
http://archives.postgresql.org/message-id/17021.1234474178@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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-05 01:31:30 Closing some 8.4 open items
Previous Message Alvaro Herrera 2009-04-04 23:49:32 Re: Python 3.0 does not work with PL/Python