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:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] (null) != (null) ?
Next
From: awer
Date:
Subject: (no subject)