4 ms·

Yes, because it is a null reference. SQL's null is a value. The difference is that processing null values does not cause exceptions in SQL.

rixed 9y ago
It doesn't cause early terminations but it certainly does cause errors.
- MarkusWinand 9y ago
  *Edit: exceptions :)
hjjiehebebe 9y ago
The problem with nulls in c++ etc. is that every reference type is forced to be nullable. There is no opt out of that semantics. You get passed in an object of type O and it is really a sum type of O + Nothing. It means you need to do runtime checks everywhere and reason across call boundaries. You need to look at he code inside that method! That so un-OO! In Db land you can make a column not nullable. Bit the SQL languages like PLSQL TSQL etc have the same issue.
- Sharlin 9y ago
  C++ references are non-nullable by design. They are sane in that regard. Pointers are nullable, of course, but at least they are syntactically conspicuous and anyway pretty rare in modern C++.
- heavenlyblue 9y ago
  I would add: the reason it is a issue in C++ is because the algebra around pointers doesn’t support the NULLs explicitly: - the results of any operations over nulls run as if the pointer were not null - while anyhing you do in SQL with NULL would explicitly have a mapping to either a correct value or another NULL This is all said knowing that it’s quite easy to understand why is that the case.
techno_modus 9y ago
> SQL's null is a value. It is known to be one of the major controversies because originally NULL means the absence of a value which entails that it is not a value. Hence, if there are no values, then we cannot do any operations. Yet, for whatever reason (avoiding exceptions etc.) expressions with NULL need to be evaluated and hence NULL is treated as a value. So we get a problem: NULL is not a value AND NULL is a value. There are different views on this problem and the solution implemented in SQL (and three-valued logic) is probably not the best one.
- MarkusWinand 9y ago
  This is a controversy outside of SQL. SQL is pretty clear what null is: > “Every [SQL] data type includes a special value, called the null value,”[0] “that is used to indicate the absence of any data value”[1] (http://modern-sql.com/concept/null http://modern-sql.com/concept/null) [0] SQL:2011-1: §4.4.2 [1] SQL:2011-1: §3.1.1.12
lmm 9y ago
Which is worse. Null references are at least relatively fail-fast. SQL null propagates and so you get the error a long way away from the original source, like with Javascript's "foo is not a property of undefined".
- default-kramer 9y ago
  Exactly. I've wondered why no SQL implementation (that I know of) has optional assertions like "join exactly 1 some_table" or "select assert-not-null(some_column)". I don't see any reason why this would be a performance killer; in fact, it might even be possible to prove and then cache with the query plan.
- abiox 9y ago
  I'd guess that propagation is by design, such as for use in outer joins.

rixed 9y ago

It doesn't cause early terminations but it certainly does cause errors.

MarkusWinand 9y ago
*Edit: exceptions :)

hjjiehebebe 9y ago

The problem with nulls in c++ etc. is that every reference type is forced to be nullable. There is no opt out of that semantics. You get passed in an object of type O and it is really a sum type of O + Nothing. It means you need to do runtime checks everywhere and reason across call boundaries. You need to look at he code inside that method! That so un-OO! In Db land you can make a column not nullable. Bit the SQL languages like PLSQL TSQL etc have the same issue.

Sharlin 9y ago
C++ references are non-nullable by design. They are sane in that regard. Pointers are nullable, of course, but at least they are syntactically conspicuous and anyway pretty rare in modern C++.
heavenlyblue 9y ago
I would add: the reason it is a issue in C++ is because the algebra around pointers doesn’t support the NULLs explicitly: - the results of any operations over nulls run as if the pointer were not null - while anyhing you do in SQL with NULL would explicitly have a mapping to either a correct value or another NULL This is all said knowing that it’s quite easy to understand why is that the case.

techno_modus 9y ago

> SQL's null is a value. It is known to be one of the major controversies because originally NULL means the absence of a value which entails that it is not a value. Hence, if there are no values, then we cannot do any operations. Yet, for whatever reason (avoiding exceptions etc.) expressions with NULL need to be evaluated and hence NULL is treated as a value. So we get a problem: NULL is not a value AND NULL is a value. There are different views on this problem and the solution implemented in SQL (and three-valued logic) is probably not the best one.

MarkusWinand 9y ago
This is a controversy outside of SQL. SQL is pretty clear what null is: > “Every [SQL] data type includes a special value, called the null value,”[0] “that is used to indicate the absence of any data value”[1] (http://modern-sql.com/concept/null http://modern-sql.com/concept/null) [0] SQL:2011-1: §4.4.2 [1] SQL:2011-1: §3.1.1.12

lmm 9y ago

Which is worse. Null references are at least relatively fail-fast. SQL null propagates and so you get the error a long way away from the original source, like with Javascript's "foo is not a property of undefined".

default-kramer 9y ago
Exactly. I've wondered why no SQL implementation (that I know of) has optional assertions like "join exactly 1 some_table" or "select assert-not-null(some_column)". I don't see any reason why this would be a performance killer; in fact, it might even be possible to prove and then cache with the query plan.
abiox 9y ago
I'd guess that propagation is by design, such as for use in outer joins.