Re: So what's null then if it's not nothing?

In article <1135259856.681792.90350_at_g43g2000cwa.googlegroups.com>, boston103_at_hotmail.com says...
>
> > You have misunderstood me, then. I'm not proposing another way of
> > handling NULLs, just better language design and better(?) explanations.
> > '+' means perfectly normal addition, but if any term is null, an
> > exception is thrown,
>
> Ok, fine, let's assume that if any term in an expression is null, an
> exception is thrown. This kind of behaviour woud practically eliminate
> any use of NULLs, except as placeholders, as well as the need to have
> a 3VL since any expression with NULLs would just thow an exception
> rather than evaluating to NULL or UNKNOWN.

No, no change. The 'exception' explanation is just sophistry in order to avoid redefining the operators. :) When a null subexpression is encountered, exceptional processing takes over, causing the whole expression to be null regardless of operators (hence my "+ is irrelevant" comment---the operator doesn't matter because the exceptional processing takes over). I.e. expressions still "evaluate to NULL", though I prefer not to use that phrase: it makes NULL look like a value.

> This kind of behaviour
> would also force the programmer to qualify any expression with the
> IS_NULL predicate ( the sole exception to the weird
> 'uniformity'/'propagation' rule you and Hugo seem to be insisting on)
> in order to ensure that the query would not just die.

Not *any* expression. Many can be guaranteed to be non-null; in fact, only those involving nullable columns can not.

> Additionally,
> the expression optimizer has to be crippled in a way that would
> guarantee that the IS_NULL predicate is evaluated first.

I'm not suggesting to change how SQL works, only how it is explained. And even if I were, we could use some IF_NULL(<expression>, <result1>, <result2>) construct.

> The question is, why bother ? All that can be achieved today on any
> SQL database by using the 'NOT NULL' predicate or not using NULLs
> altogether.

Ummm... yeah. Which is what I do when I design databases. That is a completely different discussion.

-- 
Jon