Received: from summersault.com (nollie.summersault.com [208.196.32.199]) by postgresql.org (8.11.3/8.11.1) with SMTP id f5710fE01062 for ; Wed, 6 Jun 2001 21:00:41 -0400 (EDT) (envelope-from mark@summersault.com) Received: (qmail 75900 invoked from network); 7 Jun 2001 01:00:35 -0000 Received: from hoobella.summersault.com (HELO summersault.com) (208.196.32.195) by nollie.summersault.com with SMTP; 7 Jun 2001 01:00:35 -0000 Message-ID: <3B1ED23A.984C3159@summersault.com> Date: Wed, 06 Jun 2001 20:00:45 -0500 From: Mark Stosberg Reply-To: mark@summersault.com Organization: Summersault X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: behavior of ' = NULL' vs. MySQL vs. Standards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200106/86 X-Sequence-Number: 3305 Hello, I'm a long time Postgres user who uses MySQL when I have to. I recently ran into an issue with MySQL where this construct didn't do what I expect: WHERE date_column = NULL I expected it to work like "date_column IS NULL" like it does it Postgres 7.0.2, but instead it returned an empty result set. After conversing with some folks on the MySQL list, it was mentioned that: * "NULL is *NOT* a value. It's an absence of a value, and doing *any* comparisons with NULL is invalid (the result must always be NULL, even if you say "foo = NULL")." * Postgres handling is non-standard (even if it's intuitive.) My questions then are: 1.) What IS the standard for handling NULLs? and then 2.) If Postgres handling is different than the standard, what's the reason? To me, having " = NULL" be the same as " IS NULL" is intuitive and thus useful, but I also like appeal of using standards when possible. :) Thanks! -mark http://mark.stosberg.com/