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

In article <1133894046.516473.27860_at_f14g2000cwb.googlegroups.com>, boston103_at_hotmail.com says...
>
> > > > What do you call the domain { TRUE, UNKNOWN, FALSE }? And by the way,
> > > > haven't you argued for ages that names don't matter?
> > >
> > > Names do not matter, but the number of logical constants does. If
> > > it's more than two, then the logic is most certainly not Boolean.
> >
> > You are quibbling.
>
> I beg your pardon ? The number of logical constants, not thir names,
> is what distinguishes propositional logic from various multivalued
> logics, including various breeds of 3VLs.

You don't answer my questions; you come up with complete non sequiturs. A domain has a name. The domain consisting of the values { TRUE, FALSE } is called Boolean. There is another domain, consisting of the values { TRUE, UNKNOWN, FALSE }, which I called "3VL Boolean". You ignored the main argument in order to quibble about this name, and I asked you what I should call it in order to keep the discussion on track.

> > > > What is the type/domain of the expression following the keyword WHERE in
> > > > SQL?
> > > Clearly, the the expression is a 3VL formula as defined by the
> > > standard.
> >
> > You are still quibbling. I asked about the data type.
>
> I told you already that the data type is the set (T,F,U} with its
> associated operations. What's not clear about that ?

What you call that set.

> > > > Why should we be prohibited from storing values of this type/domain
> > > > in the database?
> > >
> > > We should not be prohibited, and the SQL'99 standard has the Boolean
> > > data type. I do not remember if the standard allows NULL for the data
> > > type. If it does, the data type name is a misnomer.
> >
> > Like "integer" is a misnomer, since integer attributes can be NULL?
>
> It surely is, but not to such a degree as with the logic.

I don't see the logical difference. And I don't see your point. Does it matter for the discussion at hand?

> > > Also, the Boolean type usefulness for storing data in the database is
> > > arguably greatly exaggerated. Firstly, it can easily be modelled by
> > > just about any other already available data type
> >
> > You can model numbers using strings, too. This is not a very good
> > argument.
>
> You provided *none* why one needs an explicit Boolean or a 3VL data
> type. Please oblige.

You might as well ask why we need integers, or strings, or decimals, or points. The burden of proof is on you to say why we should prohibit them. If you don't want to prohibit them, then what are we arguing about?

> > > > And if we did have a Boolean { TRUE, FALSE } domain in SQL, shouldn't we
> > > > be able to assign NULL to an attribute of that type?
> > >
> > > If we assign NULL to the attribute of the Boolean type, it ain't
> > > Boolean no more.
> >
> > And if we assign NULL to an integer attribute, it ain't integer no more?
>
> Of course not.

And your conclusion is ..? That for Boolean attributes, NOT NULL must be enforced at all times?

-- 
Jon