Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group