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

In article <1133987926.307730.65450_at_g14g2000cwa.googlegroups.com>, boston103_at_hotmail.com says...
> Also, what's your "main argument" regarding
> the truth values set naming that I ignored ?

You said

"NULL in the context of some domain of values, integers, characters, whatever, means an unknown/missing value (as defined by Codd and the SQL standard)."

I took for granted that a boolean domain should be among the domains you listed, for which NULL means an unknown/missing value, and pointed out the inconsistency that then arose. Another mutual misunderstanding.

> How is the crucial point
> that distinguishes the 2VL from a multivalued logic, namely the number
> of truth values is a non-sequitur ?

I don't think a "regular" unknown/missing SQL NULL for a 2VL boolean domain should be regarded a truth value. That would be inconsistent with how NULL works in other domains.

> > And your conclusion is ..? That for Boolean attributes, NOT NULL must be
> > enforced at all times?
>
> In order for Boolean attributes to remain such, yes, otherwise they
> would be not Boolean and necessarily one would be using a logic other
> than Boolean which would have much more profound implications that
> extending the integer domain with nulls.

I disagree. For consistency, I'd say that any boolean expression involving NULL booleans should evaluate to NULL, just like any arithmetic expression involving NULL integers evaluates to NULL (at least if you accept the excuse for how SUM() works:). I don't think it breaks logic more than it breaks arithmetic. If you disagree, can you give any examples of profound implications?

-- 
Jon