Re: [BUGS] (null) != (null) ? - Mailing list pgsql-bugs
From | Bruce Momjian |
---|---|
Subject | Re: [BUGS] (null) != (null) ? |
Date | |
Msg-id | 199910261744.NAA28154@candle.pha.pa.us Whole thread Raw |
In response to | Re: [BUGS] (null) != (null) ? (Todd Vierling <tv@pobox.com>) |
List | pgsql-bugs |
I have just added a paragraph about this comparison in my book. You can see it on the documentation web page under "Published book". > On Tue, 26 Oct 1999, Tom Lane wrote: > > : > Both "fieldname" definitions are identical (verified with char(2) and > : > varchar(100) in particular), and both tables contain a row with a "null" in > : > that field. However, the results don't contain the row with the "null" > : > value. > : > : NULL = NULL does not yield TRUE, it yields NULL. For that matter, > : NULL != NULL does not yield FALSE --- it yields NULL. This is a > : basic consequence of the semantics of NULL. > > !? > > I have been using such constructs on commercial databases for ages. Do you > have a link to a web-based SQL standard transcription that I could look this > up? (I'll check up on exactly which database(s) I can use this type of > construct when I get back to work tomorrow....) > > It seems _extremely_ counter-intuitive, especially in cases where both > fields are in fact the same type. > > : Nearly all Postgres operators yield NULL if any input is NULL. > > Interesting ... so see my clarification of (2) below. > > : If you really want to match up nulls in your example, you can do > : something like > : WHERE (a.fieldname = b.fieldname) OR > : (a.fieldname IS NULL AND b.fieldname IS NULL) > > Which I already described in my text, sigh. > > : This is pretty grotty, of course, so my inclination would be to > : use a special non-NULL value --- an empty string, for example --- > > Doesn't work for datetime, which is an important application in my case > which rather needs null to indicate "no datestamp at all". > > : > (2) NOT IN doesn't seem to work at all. I always get 0 results--and very > : > rapidly at that!--regardless of the situation. > : > : I don't think it's quite *that* broken. How about a concrete > : example of what you're trying to do? > > Well, after reading your statement about "Nearly all Postgres ...", here's a > very simple example that I was able to create based on that assumption: > > => create temp table foo (name varchar(10)); > => create temp table foo2 (name varchar(10)); > => insert into foo values (null); // <<- here's the tripwire! > => insert into foo values ('a'); > => insert into foo2 values ('a'); > => insert into foo2 values ('b'); > => select * from foo2 where field not in (select field from foo); > > field > ----- > (0 rows) > > Now *that* is awfully disturbing. :> > > -- > -- Todd Vierling (tv@pobox.com) > > > ************ > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
pgsql-bugs by date: