From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: NULLS and User Input WAS Re: multimaster |
Date: | 2007-06-04 14:38:01 |
Message-ID: | 466423C9.7030600@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andrew Sullivan wrote:
> On Mon, Jun 04, 2007 at 12:37:42AM +0200, PFC wrote:
>> NULL usually means "unknown" or "not applicable"
>
> Aaaargh! No, it doesn't. It means NULL. Nothing else.
>
> If it meant unknown or not applicable or anything else, then
>
> SELECT * FROM nulltbl a, othernulltbl b
> WHERE a.nullcol = b.nullcol
>
> would return rows where a.nullcol contained NULL and b.nullcol
> contained NULL. But it doesn't, because !(NULL = NULL).
Well, a strict "unknown" is fine - so long as it means just that.
How tall is Andrew? Unknown
How tall is Richard? Unknown
Are Andrew and Richard the same height? Unknown
The problem is the slippery-slope from "unknown" to "not applicable" to
"user refused to answer" to ...whatever
Part of it is the poor support for out-of-band values. In many cases
what people want is the ability to have a value of type 'number in range
1-20 or text "n/a"' and there's not a simple way to provide that, so
they use null.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-06-04 14:42:32 | Re: NULLS and User Input WAS Re: multimaster |
Previous Message | Madison Kelly | 2007-06-04 14:36:29 | Re: High-availability |