oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

I thought I was nearly done for today, then this bit me:

Consider the following queries:

(a) SELECT count(*) FROM graph;
(b) SELECT * FROM graph where latch is NULL;
(c) SELECT * FROM graph where latch='';
(d) SELECT * FROM graph where latch='0';


In my debug build, (a) and (b) reutrn the same - the set of pairs,
and (c) and (d) the same - the set of vertices in linkid aka no_search

My understanding of the requirements is that the above is the correct
behaviour, is this true?

BUT

In the default cmake build, (b) returns the same as (c) and (d)

Thus, case (b) `is NULL` has a problem...

Some initial observations after I eventually had to resort to gdb indicate
that the debug build uses the random scan (edges cursor) and the normal build
ends up doing a no_search for is NULL.

This is crazy!

Only thing I can think of is, somewhere, a variable is not initialised and
gets set differently in the debug build?

The code passes through index_read_idx() for the default build for `is NULL` ,
producing the incorrect behaviour, and doesnt for the debug build.

This is frustrating!  This causes the basic.test to fail...

The entry points are external to our code, indicating the query optimiser is
making the choice to pass `is NULL` as a where clause to one path or the other
(my best estimate given my limited knowlegde of the inner workings of mysql)

My debug build appends -DCMAKE_BUILD_TYPE=Debug"

--ANdrew