From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | dev(at)archonet(dot)com, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: RFC: A brief guide to nulls |
Date: | 2003-01-16 04:20:22 |
Message-ID: | 11445.1042690822@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> dev(at)archonet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rudi Starcevic | 2003-01-16 06:10:42 | pg_dump problem |
Previous Message | Matthew Nuzum | 2003-01-16 03:46:48 | Re: show data from two tables together |