[dragonwriter]

> And in many contexts in SQL, NULL is treated as equivalent to false, such as within a WHERE clause.

NULL is not equivalent to FALSE, it is neither FALSE nor TRUE. It has the same effect as FALSE as the final result of evaluating a WHERE clause condition only because WHERE clause conditions allow a row to be included only when they evaluate strictly to TRUE. But if NULL were equivalent to FALSE in a WHERE clause, than a WHERE clause condition which would evaluate to NULL that was instead negated would be equivalent to TRUE but instead it remains NULL which remains not TRUE.

[Pxtl]

No, because NOT NULL/UNKNOWN is still NULL/UNKNOWN.

I realized earlier I was using the term NULL, but going forwards let's use the ANSI SQL concept where the null state of a Boolean is called UNKNOWN. You'll have to forgive me for using the term NULL this far, but in my defense the concept of NULL column-values and UNKNOWN boolean expression results are pretty intertwingled.

    SELECT * FROM foo WHERE NOT (1 = NULL)

resolves to

    SELECT * FROM foo WHERE UNKNOWN

which is the same value that

    SELECT * FROM foo WHERE 1 = NULL

resolves to.

So the WHERE clause is treating UNKNOWN/NULL as equivalent to false. The rest of the Boolean algebra is not.

SQL likes to have it both ways. Sometimes UNKNOWN/NULL is equivalent to false sometimes it's not.

It does this because UNKNOWN/NULL Booleans are incredibly inconvenient and tedious and sometimes they'd rather not think about them.

I'd like to do that as well, but this hoary old language won't give me the same permission it gives itself.