"Mark Cave-Ayland" <[EMAIL PROTECTED]> writes: > As far as I can tell this is the case. What I've done to test this is to > put an elog(NOTICE, ".....") in geometry_overlap()
Well, I can easily prove that CVS tip does call the operator function and honor its result. regression=# create table foo (f1 float8 unique); NOTICE: CREATE TABLE / UNIQUE will create implicit index "foo_f1_key" for table "foo" CREATE TABLE regression=# insert into foo values(1); INSERT 480998 1 regression=# insert into foo values(2); INSERT 480999 1 regression=# select * from foo where f1 = 1; f1 ---- 1 (1 row) With gdb, I set a breakpoint at float8eq, and determine that it is called exactly once (during _bt_checkkeys' scan setup) in this query. Next, after some fooling about to determine which row in pg_amop describes float8eq: regression=# update pg_amop set amopreqcheck = true regression-# where amopclaid = 1972 and amopsubtype = 0 and amopstrategy = 3; UPDATE 1 Now the select calls float8eq twice, once from _bt_checkkeys and once from IndexNext. Moreover I can force a zero result from float8eq in the second call, and if I do then no rows are returned. My guess is that your problem occurs because the index is not returning the row in the first place, and thus there is nothing to recheck. This would point to a bug somewhere in your GIST support functions. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly