|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
For 4.2... maybe.
As I mentioned to you on IRC, I am not a fan of treating null comparisons as deterministic. Perhaps it is my extensive background on databases, but nulls are special and comparisons against them are non-deterministic. For example, even the debate in
HHH-2951shows the general misunderstanding. When they say that the check something = null "always returns false" that is actually completely inaccurate. ANSI SQL defines 3 truth values: TRUE, FALSE and UNDEFINED (or UNKNOWN). Comparisons involving nulls actually always resolve to UNKNOWN.I guess the question here is whether we want this to follow SQL semantics or this more arguably user-helpful form. My argument with the user-helpfulness is that we might be hiding subtle coding bugs in the user code.