Re: NULLs: theoretical problems?

From: -CELKO- <jcelko212_at_earthlink.net>
Date: Sat, 11 Aug 2007 20:21:53 -0700
Message-ID: <1186888913.655658.136450_at_r34g2000hsd.googlegroups.com>


>> Proving that you did not know the difference between logical and physical. Of course a NULL needs to be implemented, but it is _not_ a value. Any possible implementation (and there are lots) will have to be some sort of special case, but the language does not need to know. <<

I thihk it demonstrates that you have never worked on an ANSI or ISO committee or written a compiler :) You might want to look at the IEEE Floating Point Standards and their "special values" -- +inf, -inf, Nan, etc. Much more complex than a mere NULL! While IEEE does give the "bits and bytes" for their special values, we left implementation open but borrowed the accepted terminology from them.

>> ["CAST (NULL AS <data type>)" to signal the SQL compiler about that column's storage] What on earth does that mean? <<

I thought that was pretty clear. SQL stores data; data has a srong data type in SQL; the compiler needs to know about it to make decisions and allocations.

>> [ CASE expression without explicit CAST() help] I dont't know that I actually believe that. <<

I will see if I can find one for you tomorrow -- I am babysitting my niece's two year old tonight and have to use her Mac.

>> But then floating-point numbers are values that are difficult to represent, whereas NULL is _not_ a value, but is easy to represent. The arguments are about what it means and whether we really need it. <<

Hey, I am just providing information about SQL. I happen to think that NULLs can be hard to represent because they have to work with all kinds of data types, whereas I can burn the IEEE rules into a Math Coprocessor  at the hardware level. Received on Sun Aug 12 2007 - 05:21:53 CEST

Original text of this message