Few updates for decisive eq op

Found the problem you are dealing with:

While running test_ne in TestSetOps, try this:

select 
    *, 
    "a.$number"="b.$number", 
    "a.$number" is null,  
    "b.$number" is null, 
    ("a.$number" is null and "b.$number" is null) AS both_null 
from 
    testing

I did this because the database was returning the wrong rows. The logic looked good, but where did it go wrong. All declarative languages are like this: They are wonderful to read, maybe a delight to write, but if your declaration is wrong, you will spend a long time figuring out why. SQL is not pure declarative, more functional, so it is not impossible to debug, but still harder than stepping through with your debugger.

I listed all the intermediate logic steps over all records to verify each step.

{
    "header": [
        "_id", "__id__", "a.$number", "b.$number", "\"a.$number\"=\"b.$number\"", "\"a.$number\"isnull", "\"b.$number\"isnull", "both_null"],
    "meta": {"format": "table"},
    "data": [
        ["27a18f5a-7dd3-4380-9ef0-c8f4ef12053e", 1, 0, 0, 1, 0, 0, 0],
        ["0849a16b-132a-45ce-8a43-46b5f469ee55", 2, 0, 1, 0, 0, 0, 0],
        ["64bba272-117e-4b8b-b6e9-76f02dd9b410", 3, 0, null, null, 0, 1, 0],
        ["cdc049fb-5ce8-4430-9800-d80c3b00bc8d", 4, 1, 0, 0, 0, 0, 0],
        ["a1ff07e5-a49c-485f-b991-9e96f3e3caff", 5, 1, 1, 1, 0, 0, 0],
        ["0037bab9-d2da-4355-8825-4795c94956d3", 6, 1, null, null, 0, 1, 0],
        ["d57dbac4-15c8-452a-a0b2-2b4e876579aa", 7, null, 0, null, 1, 0, 0],
        ["86bea9f6-e487-4212-9133-dc188ab6f5df", 8, null, 1, null, 1, 0, 0],
        ["58f29ae0-ef04-4331-81bf-cc0e12e7f5d6", 9, null, null, null, 1, 1, 1]
    ]
}

Notice the nulls! 1=null returns a null, not false. There for not(1=null) also returns null, which is "falsey" in the where clause.

First eq is not returning the correct values; it should not be returning null at all.

mozilla / jx-sqlite

Few updates for decisive eq op #54