Effects of NULL Operator

As a general rule-but not a universal one-if NULL is an argument to an invocation of a system-defined read-only operator, then NULL is the result of that invocation. As you can see, the code for HIGHER_OF includes A > B, an invocation of the system-defined read-only operator ">", which does follow the general rule. Hence, if NULL is substituted for either or both of the parameters A and B, then NULL- which in this case we can also call UNKNOWN because ">" is a Boolean operator-is the result of the invocation. You are perhaps now wondering how SQL handles the IF statement when the specified condition yields UNKNOWN: is the THEN clause evaluated, or is it the ELSE clause?

As you know, other programming languages are normally based on classical logic. In keeping with the existence of just two truth values, TRUE and FALSE, the syntax for IF statements (and IF expressions) in such languages has just the two forks, THEN for when the condition is TRUE, ELSE for when it is not (i.e., is FALSE). You might therefore reasonably expect a language that embraces n truth values to support a variety of IF that has n forks-under a language design principle that Fred Brooks referred to as conceptual integrity, which means adhering rigorously to the language's adopted concepts. Instead, SQL retains just the two forks, keeping the normal treatment of THEN as being the one for when the condition is TRUE and arbitrarily lumping UNKNOWN in with FALSE for the ELSE fork. You should now be able to see that the general rule ("NULL in, NULL out") for system-defined operators cannot be said to apply to user-defined ones. If A > B evaluates to UNKNOWN, then the result of the HIGHER_OF invocation is the argument substituted for B, which might or might not be NULL.