To: Peter Eisentraut <peter_e@gmx.net>
Cc: dev@archonet.com, pgsql-sql@postgresql.org
Subject: Re: RFC: A brief guide to nulls 
In-reply-to: <Pine.LNX.4.44.0301152037180.789-100000@localhost.localdomain> 
References: <Pine.LNX.4.44.0301152037180.789-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Thu, 16 Jan 2003 00:44:55 +0100"
Date: Wed, 15 Jan 2003 23:20:22 -0500
Message-ID: <11445.1042690822@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:
> dev@archonet.com writes:
>> A null is *not* a value.
>> A null is *not* a "special" value.
>> A null is the absence of a value.

> A quotation directly from the SQL standard:
>     Every data type includes a special value, called the null value,
> This seems to directly contradict those three statements.

I think you can look at it either way.  The traditional mathematical
approach to this sort of thing has been to consider that every data
type includes an "undefined" value (sometimes called "bottom", often
written as an upside-down T).  But the specific semantics assigned to
this concept in SQL definitely correspond to the idea that there's
a missing data entry.  And those who like to think about the bits prefer
to imagine a separate "its-null" flag bit, as someone else noted in this
thread.

The real bottom line is that the language provides you with a concept
"NULL" that has very specific (and less than intuitive) semantics.
To make use of this concept in your application, you have to interpret
it in a way that is useful for your application --- and doesn't conflict
with the SQL-defined semantics.

			regards, tom lane