From: | "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | ctassell(at)isn(dot)net, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Can't use NULL in IN conditional? |
Date: | 2000-12-12 05:01:28 |
Message-ID: | 0012120001281T.00289@comptechnews |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Monday 11 December 2000 12:34, Tom Lane wrote:
> Three-valued logic is perfectly straightforward if you keep in mind the
> interpretation of NULL/UNKNOWN: "I don't know if this is true or false".
> Thus:
>
> NOT unknown => unknown
>
> false AND unknown => false (it can't possibly be true)
> true AND unknown => unknown
> unknown AND unknown => unknown
>
> false OR unknown => unknown
> true OR unknown => true (it's true no matter what the unknown is)
> unknown OR unknown => unknown
>
> For ordinary operators such as "=", the result is generally NULL if any
> input is NULL, although there are some specific cases where you can
> deduce a correct result knowing only some of the inputs. In particular,
> NULL = NULL does not yield TRUE, it yields UNKNOWN. This is correct
> when you consider that NULL is not a specific value, but a placeholder
> for an unknown value. (Reference: SQL99 section 8.2 general rule 1a.)
>
> IS NULL and IS NOT NULL are not ordinary operators in this sense, since
> they can deliver a non-null result for NULL input.
>
> Also, SQL specifies that a WHERE clause that evaluates to "unknown" is
> taken as false, ie, the row is not selected.
>
> Bottom line is that in a spec-conformant implementation,
> WHERE code = '0A' OR code = NULL
> will act the same as if you'd just written "WHERE code = '0A'"; the
> second clause always yields unknown and so can never cause the WHERE to
> be taken as true.
>
> > Some newer implementations of SQL
> > eliminate UNKNOWN, and may generally behave as follows: all boolean tests
> > involving NULL return FALSE except the explicit test IS NULL, e.g., if
> > NULL is a possibility, it has to be tested for explicity using IS NULL or
> > IS NOT NULL.
>
> They may *appear* to return FALSE if you aren't looking too closely,
> since WHERE treats top-level results of FALSE and UNKNOWN the same.
> If they really don't make the distinction then they are broken.
> AFAICT, neither SQL92 nor SQL99 regard NULL support as optional.
>
> regards, tom lane
Thanks for the clarification and SQL reference. I spent some time on this
today and updated a file of mine at
http://www.comptechnews.com/~reaster/dbdesign.html#three-valued-logic
to take into consideration these things. If you do take a look at it and
find an error, I will fix it. This dbdesign.html file is a file linked to
from http://postgresql.readysetnet.com/docs/faq-english.html so I'm hoping to
keep it correct and useful. Thanks :)
--
-------- Robert B. Easter reaster(at)comptechnews(dot)com ---------
- CompTechNews Message Board http://www.comptechnews.com/ -
- CompTechServ Tech Services http://www.comptechserv.com/ -
---------- http://www.comptechnews.com/~reaster/ ------------
From | Date | Subject | |
---|---|---|---|
Next Message | Dronamraju Rajesh | 2000-12-12 05:55:52 | LockReplace: xid table corrupted |
Previous Message | Markus Brachner | 2000-12-11 21:32:36 | PostgreSQL 7.0.3 freeze |