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

From: vc <boston103_at_hotmail.com>
Date: 15 Dec 2005 03:27:32 -0800
Message-ID: <1134646052.578144.164260_at_f14g2000cwb.googlegroups.com>


Jon Heggland wrote:
> In article <1134593763.282919.322250_at_z14g2000cwz.googlegroups.com>,
> boston103_at_hotmail.com says...
> >
> > Saying that two truth tables are the same should make it blindingly
> > obvious that there is no room to weasel out and say that NULL != NULL
> > in this context.
>
> Strange that the SQL committee is just as blind as me to the blindingly
> obvious, then.

Great minds think alike.

>
> > If one insists on NULL != NULL in the context of
> > truth values, then the truth tables clearly are not the same. Using
> > IS_NULL is just a trick serving to fix the broken, for no good reason,
> > equality predicate over the domain of truth values. IS_NULL does not
> > contribute anything substantial to the crucial decision to consider the
> > two tables containing NULLs to be equal.
>
> It may be "just a trick", but so what? SQL commonly considers tables
> containing NULLs to be equal in other contexts anyway---for purposes of
> union and intersection, for example. NULLs are (seemingly) sometimes
> equal and sometimes not; it's no problem to consider them equal for
> truth table comparison purposes.
>

That's a possible interpretation (having two different equaity predicates) as I mentioned in my earlier message on 'meta' vs. 'object' language, but completely unnecessary since a simlpler interpretation would suffice especially when backed up by common sense. While one can argue that the rationale for NULL = NULL evaluating to FALSE, say, in the integer domain makes sense because we presumably do not know whether NULL represents the same values, one cannot do so in the domain of truth values where UNKNOWN (aka NULL) represents *the same* degree of truth (if one wants to have n degrees of truth, one uses n-VL). Therefore, sacrificing simplicity and common sense for the sake of 'uniformity' does not apper to be a very clever decision. Regarding 'uniformity', witness TRUE OR NULL evaluatiing to TRUE, not NULL as a uniformity purist would expect.

> > > SQL-99 seems to use "my system" (it isn't *my* system, though; I think
> > > it's badly designed). Can you provide a SQL example where there is a
> > > serious problem?
> > >
> >
> > I gave you examples of simple logical expressions not being equivalent
> > in my earlier response. You can easily imagine any SQL using such
> > expressions.
>
> So transformations for optimisation is your only objection?

No, and you can easily locate my other objections in the earlier messages.

>

[...]
> > Of course, the real life database engine
> > designers are not so stupid as to blindly adhere to the nonsensical
> > standard stating that one cannot compare some truth values and do
> > consider two truth tables with NULLs (or UNKNOWNs) in the maching rows
> > to be in fact the same (of course if other matching rows contain the
> > same not-NULL/not-UNKNOWN values).
>
> Aren't they then just doing what I am suggesting: using a "trick" to
> compare truth tables? What database engines and designers are you
> talking about, by the way?

Folks who wrote SQL Sever, Oracle, et.

> --
> Jon
Received on Thu Dec 15 2005 - 12:27:32 CET

Original text of this message