Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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
