Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: >> Anyway, I think you probably need to load up the old debugger and put a >> break point in the overlap function ... surely the error can't be in >> float4in or else we'd have seen other regression problems. > > One of the failing test cases is for seg_over_left, which is so trivial > that it's pretty hard to believe even a Microsoft compiler could get it > wrong ;-). My bet is something wrong in segparse.y or possibly > segscan.l, leading to garbage seg values being produced. We've seen > segparse.y trigger compiler bugs before --- look at its CVS history.
Loading up the debugger (I'm so happy not to have gdb-win32 now :-P), I get some interesting stuff. My test case is "SELECT '1'::seg && '2'::seg" which should return false, but returns true. I also tried seg_overlap('1'::seg,'2'::seg) to make the path easier, but same problem - still returns 't' when it should return'f'. The SEG parameters going into seg_overlap() look perfectly correct, and seg_overlap() actually returns 0. But this is somehow later turned into 't'. Any pointers for where to look for how that happens? For example, calling seg_same('1'::seg,'2'::seg) works fine, so it's not something in general with bool functions, or with the input functions. In fact, those two functions looks very very similar to me. //Magnus ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend