On Friday 25 June 2004 09:37, Rosser Schwarz wrote:
On Fri, 25 Jun 2004 08:16:47 +0400, sad <[EMAIL PROTECTED]> wrote:
Very simply, a boolean may have to values: true or false. It's also possible that it's not been set to anything (NULL).
really ? what about (13 < NULL)::BOOL
Per the semantics of NULL, 13 is neither greater than nor less than NULL. NULL is the *unknown* value; it's impossible to meaningfully compare it to anything else. Try (NULL = NULL)::boolean. It's NULL, also.
READ THE THREAD BEFORE ANSWER
WHAT MAKES YOU THINK HE HASN'T? OH, AND WHY ARE WE SHOUTING?
Your main argument seems to be:
1. A boolean value may have 3 states: true/false/null
2. The "if" statement has only if/then/else/endif
3. The "if" statement needs to be expanded to include "elsenull" or similar.
Now, you can argue for/against special-casing nulls, but all other languages cope with defined(), isset() etc. tests.
The key point of argument, and where the problem is with your (13 < NULL)::BOOL point is this:
- Boolean _values_ can have one of two states: true/false
- Boolean _variables_ can have one of three states: true/false/null
What you had in your example was an undefined boolean variable, not a boolean value with a third state. You can argue that the null in question is of type boolean (I don't), but it is explicitly _not_ a value.
Now, your point that:
IF (...)=true
is not the same as
IF NOT((...)=false)
is a good one. Handling of NULLs causes a great deal of pain to inexperienced and experienced developers alike. You might be interested in the archives at http://www.dbdebunk.com/ which IIRC contains some articles arguing against nulls at all in a relational system.
-- Richard Huxton Archonet Ltd
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
