Re: So what's null then if it's not nothing?

In article <1134679339.048493.78900_at_z14g2000cwz.googlegroups.com>, boston103_at_hotmail.com says...
>
> However, his subsequent analogy "After all, it is very common in
> mathematics to label unknown values by letters such as m, n, x, y, z."
> is not very enlightening. Nowhere did he say, though, that UNKNOWN is
> a variable.

He doesn't use the word 'variable', true. So it's not totally clear cut.

> One can infer the 'variable' meaning from "The fact that the letters m,
> n do not "look like" any of the integers does not prevent them from
> actually having integer values in an expression such as m + n, m - n,
> or an assertion that m * m = m.", but it would be a strange
> interpretation.

Hardly. The analogy must be that 'unknown' can actually *have* a truth value (true or false), which implies that it cannot actually *be* a truth value.

> In fact, he said: "an RDBMS must be able to determine
> whether NOT A, A OR B, and A AND B is true, false, or unknown when A,
> or B, or both are unknown" which clearly means that 'unknown' is a
> truth value a logical expression may evaluate to.

Well, for integers, an RDBMS must be able to determine whether A + 1 is 2, 3, or unknown when A is 1, 2 or unknown, too. That doesn't mean that 'unknown' is an integer. It is clear that a logical expression may evaluate to unknown, but it is *not* clear whether Codd considers this 'unknown' a regular truth value. *I* think it is likely that Codd considered a 'missing' (null) boolean and the 3VL truth value UNKNOWN the very same thing.

> > My preferred solution would involve an actual truth value called (e.g.)
> > UNKNOWN, distinct from NULL, and equal to itself (of course). So my
> > "destroying" logic would be limited to allowing truth value variables to
> > be NULL, letting those NULLs propagate, and not considering NULL part of
> > the truth value domain (or any domain at all).
>
> How can you reconcile the idea of an element being a member of some
> set/domain due to the fact that one can apply all the domain's
> operations to the element and store the element along with other domain
> values , and *at the same time* not being a member of such domain?

That is how all other NULLs work! NULL is not a string or a number either, and if you apply operations to it, all you get is NULL.

> Further, instead of having a three-valued logic, you've created a
> four valued logic with some strange rules for its usual connectives
> (How can one interpret the rule that TRUE OR 'YOUR_NULL' is no longer
> true ?

Just like you interpret that 0 * NULL is not 0.

> How would you rationalize such OR ? Also, you did not solve
> the problem with the truth tables being equal since they now contain
> 'YOUR_NULL' which makes them incomparable.

I just leave NULL out of the truth table. It is meta-information. Alternatively, I can compare them using IS NULL.

> > > What I meant was that Oracle people were sensible enough to regard the
> > > expressions with the same truth tables, even containing nulls, as
> > > equivalent which is evidenced by the optimizer behaviour in spite of
> > > the nonsensical interface they present to the end user. They did not
> > > have much say in this matter but try and conform to the standard.
> >
> > This is exactly what I suggested, and probably what the SQL committee
> > intended.
>
> I am not sure what you've suggested. Was that some truth table rows
> (containing NULL) cannot be regarded as equal and yet the truth tables
> can be considered equal ?

Like I said, what you just described as sensible: That you can consider truth tables equal even when they contain NULLs.

-- 
Jon