On Tue, Oct 27, 2009 at 9:35 PM, John Crenshaw <johncrens...@priacta.com> wrote: > Meh, I don't want it THAT badly. I'm just saying that's how it should > have been in the original design of the SQL language. In fact though, it > probably wouldn't have mattered. Every different RDBMS seems to treat > nulls differently in this regard, so I'm not even sure exactly what the > spec says on the issue (most likely, SQLite is exactly in line with the > spec, but I haven't bothered to confirm that.)
The problem is that you only have one concept of NULL, but any particular case where something is NULL could come from a different source than another case. Think of NaN in numerics. You probably don't want the NaN from 0/0 to compare equal to the NaN from sqrt(-1), but expressing what you do want to do for each possible case of NaN is hard and prone to mistake. While an implementation must represent NULL as a value, NULL is not a value. Saying "5 <> NULL" is not a sensible statement, because 5 is as equal to NULL as it is unequal to NULL, or greater than NULL, or less than NULL. You can't compare them, because one is a scalar value, and the other is absence of a value. You're doing a divide-by-zero, and syntactic sugar will not resolve that. Check out http://en.wikipedia.org/wiki/Null_(SQL)#Criticisms and just be glad you don't have to deal with two or three distinct flavors of NULL! -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
