Tony Andrews in another question gave an example of:
IF p_c_courtesies_cd || p_c_language_cd || v_c_name || v_c_firstname || v_c_function || p_c_phone || p_c_mobile p_c_fax || v_c_email is not null THEN -- Do something END IF; as a clever (if not a tad obscure) alternative to the Oracle COALESCE function. Sure enough, it works, if any argument is not null, the IF test is true. My question: Is Oracle’s implementation of the above concatenation operation SQL-92 conforming? Shouldn’t an expression involving a NULL evaluate to NULL? If you don’t think so, then why should the expression 1 + NULL evaluate to NULL?
No, Oracle’s treatment of nulls is idiosyncratic, different from everyone else’s, and inconsistent with the ANSI standards. In Oracle’s defence however, it probably settled on and was committed to this treatment long before there was an ANSI standard to be consistent with!
It all starts from the fact that Oracle stores strings with a character count followed by the string data. A NULL is represented by a character count of zero with no following string data – which is exactly the same as an empty string (”). Oracle simply doesn’t have a way to distinguish them.
This leads to some quirky behaviour, such as this concatenation case. Oracle also has a function LENGTH to return the length of a string, but this has been defined in an opposite manner, so that LENGTH(”) returns NULL not zero. So:
which seems to me to violate basic mathematical principles.
Of course, Oracle developers become so used to this that many of us can’t even see anything wrong or odd about it – some will in fact argue that the rest of the world is wrong and that an empty string and a NULL are the same thing!