Re: new version of contrib-intarray
От | Tom Lane |
---|---|
Тема | Re: new version of contrib-intarray |
Дата | |
Msg-id | 2794.984964984@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: new version of contrib-intarray (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: new version of contrib-intarray
|
Список | pgsql-hackers |
I wrote: > I did this, also reinstalled the include-file changes I had made, and > then spent several fruitless hours trying to find why the "intbig" index > operators fail selftest here (on HP-PA). I suppose it's a portability > problem, since presumably they pass for Oleg ... but I don't see it. Further experimentation shows that intbig fails selftest on ALL platforms under 7.1. I see the problem: the intarray operators are mostly unprepared to cope with TOASTed input arrays. In particular, _intbig_union() generates an erroneous "null" result for a compressed input array, leading to completely incorrect GiST index trees in the self-test example. A somewhat-related error in this code is that some routines feel free to scribble on their input. This is tres uncool, because they may be scribbling on disk buffers. Example: regression=# create table foo(f1 int4[]); CREATE regression=# insert into foo values ('{10,1,2,1,4}'); INSERT 150265 1 regression=# select * from foo; f1 --------------{10,1,2,1,4} (1 row) regression=# select * from foo where f1 && '{4}'; f1 --------------{1,1,2,4,10} (1 row) regression=# select * from foo; f1 --------------{1,1,2,4,10} (1 row) And you thought SELECT was a read-only operation ... I do not have time to work on this stuff now, but as it stands the contrib/intarray code is unusable in 7.1. Unless Oleg can find the time to fix these issues before release, I will recommend that we not ship contrib/intarray in 7.1. regards, tom lane
В списке pgsql-hackers по дате отправления: