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

Hugo Kornelis wrote:
[...]
>... - in the SQL-99 standard, a BOOLEAN (sic!) datatype
> is introduced. According to the description in the standard, a boolean
> value is either True or False. "The truth value of _unknown_ is
> sometimes represented by the null value".

The '99 standard is terribly confused with respect to its new 'Boolean' data type. Firstly, the name itself is wrong because they clearly use a 3VL (see the truth tables for AND, OR, NOT); secondly they have *two* names/synonyms for the same truth value (UNKNOWN, NULL), thirdly they define comparison predicates over their 'Boolean' domain which has about as much sense as defining multiplication for strings. Finally, we still do not know, since they do not provide the material implication truth table, what exact kind of logic they propose in the standard.

>
> If a data type accomodates not only True and False but Unknown as well
> (represented in whatever way), I'd hesitate to call it Boolean, since
> most people associate the term Boolean with the most simple Boolean
> algebra, that has only True and False. But on the other hand, if all
> rules for a Boolean algebra are met, there's technically no reason to
> object to the name Boolean for this data type.

Even though, their logic has three truth values ? How can one say that there is "no reason to object to the name Boolean for this data type" ? You are contradicting yourself.

>
> There is a reson to object to the use of "the null value" to represent
> the truth value Unknown. Elsewhere in the standard, the Null value is
> defined as "A special value that is used to indicate the absence of any
> data value". Of course, if Unknown is considered to be a data value for
> a boolean data type (and the rest of the standard clearly indicates it
> is), it should not be represented by the same symbol that is also used
> to represent the absence of a data value, since a data value can not be
> absent and present at the same time.

Right.

>
> Further in the document, in the part where <boolean value expression> is
> detailed, the boolean truth tables are given. According to these tables,
> False AND Unknown should evaluate to False and True OR Unknown should
> evaluate to True. Makes sense. But since Unknown and NULL are considered
> equal in the context of a Boolean data type, this also means that False
> AND NULL evaluates to False and True OR NULL evaluates to True. The
> basic rule of NULL propagation is out of the window!!

Apparently, whoever created this part of the standard had no clue about what any kind of logic is.

>
>
> I had read somewhere that the Boolean data type is no longer defined in
> the SQL-2003 standard. Based on the above, this doesn't come as a
> surprise :-) However, a quick search on internet brought me to a
> (probably draft) copy of the SQL-2003 standard that still does include
> the Boolean data type, exactly as it was in SQL-1999. Shame. :-((

Funny, aint it ?

>
>
> >> But if we have to define seperate results for FALSE AND TRUE, FALSE AND
> >> UNKNOWN, FALSE AND FALSE, and FALSE AND NULL, then we are clearly no
> >> longer dealing with the original 3VL logic tables that are mentioned in
> >> rule 3 above. Rather, we are extending them.
> >
> >Isn't it possible to say we are dealing with the normal 3VL tables
> >(without NULL), but that they only apply when there are no NULLs? After
> >all, NULL is not a value. Smells bad, perhaps, but I don't really see
> >the difference compared to how other domains deals with NULL.
>
> It's good that you see no difference compared to how other domains
> handle NULL, because there should not be any difference.

What do you mean by "there should be no difference" ? Could you, like, substantiate the requirement of there being no difference ? Or is it just a matter of convenience, requiring that any expression where NULL is present should be avaluated to NULL ? What's so sensible, for example, in demanding that 'zero times NULL' should be equal NULL ? Can you imagine any integer value, however unknown or temporarily missing, having been multiplied by zero and producing anything but zero ?

>
> >
> >> While this might theoratically and technically work, I don't like the
> >> idea. There are already too many people flabbergasted by 3VL - what
> >> would "4VL" do for them?
> >
> >No need to call it 4VL. NULL is not a value. How NULL "works" is easy to
> >remember; it destroys everything it touches (I.e. all expressions
> >involving NULL evaluate to NULL (exceptions excepted)). For the rest,
> >you have the normal 3VL truth tables.
>
> Removing the row and column for NULL from the truth tables and replacing
> them by a line that says that NULLs propagate changes only the
> representation of the tables, not the content. You're still dealing with
> logic that has to accomodate for four possibilities: the three values
> True, Unknown ald False, and the "special value" NULL.
>

Right.

> >
> >> For me, it's just too many problems for too little gain.
> >

It's actually possible to express some folks' dream about having a 'uniform' NULL, although only partially, in all the domains. Say, one can use NULL as a truth value and require that 'NULL equals NULL' should evaluate to NULL for truth values as well. Then, in order to salvage the logical equivalency based on the notion of truth tables being the *same*, one can say: 'Oh, and by the way the equality predicate when at least one argument is NULL evaluates to NULL in the *object language *, but in our metalanguage, where we talk about expressions, we have another equallity predicate that evaluates 'NULL=NULL' to TRUE. I am not sure, though, that much can be gained by introducing this 'meta' and 'object' talk. Besides, NULL behaviour would still be not quite uniform because, for example, TRUE OR NULL would evaluate to TRUE (hopefully).

>
> (Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Mon Dec 12 2005 - 03:23:17 CET