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

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 05 Dec 2005 18:17:55 GMT
Message-ID: <nv%kf.52367$Gd6.22718_at_pd7tw3no>


vc wrote:
> Jon Heggland wrote:
>

>>In article <1133736634.236543.68290_at_g43g2000cwa.googlegroups.com>,
>>boston103_at_hotmail.com says...

>
> ......
>>>>And it seems a curious omission indeed. TTM considers boolean the *only*
>>>>datatype/domain that *must* be supported.
>>>
>>>I imagine that TTM just does not need unknown because it uses the 2vl.
>>
>>That's not my point. The point is that a DBMS should support a truth
>>value datatype.

>
>
> I am not sure, as I said before, that the data type is so terribly
> important for storing data. TTM does not provide any rationale for the
> must-be-supported data type.
> ...

TTM, I'd say, mostly gives rationales for implementation choices. It assumes quite a lot of background that the authors have written about elsewhere. At the risk of twisting their intent, I'd say that the reasons are clear even if they're not spelled out explicitly in TTM and even if one must read between the lines here and there.

(Note that I'm not claiming to be a TTM expert - it is a regular struggle for me but I find my meagre progress rewarding.)

For one thing, the only way, without going outside the relational operators (eg. without counting returned 'rows' or checking 'return codes' or 'status codes') to find out if a relation has any true propositions is to support a value such as 'TRUE'. I believe TTM effectively considers TRUE to be equivalent to a projection over zero columns of a non-empty relation. Basically, it seems to be TTM's way of being able to give an answer within the algebra that supports FOL's existential quantifier, ie. the result of the question is in fact a relation.

I'd say that ought to be rationale enough, but there do seem to be some related practical uses of tables with no columns.

cheers,
p Received on Mon Dec 05 2005 - 19:17:55 CET

Original text of this message