Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Date
Msg-id 9495.992009825@sss.pgh.pa.us
Whole thread Raw
In response to AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
List pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> Actually I am not sure whether the column = NULL syntax is even defined 
> or allowed in SQL92 (e.g. Informix interprets the NULL as column name in 
> this context and errs out).

Strictly speaking, SQL92 would require you to writefoo = CAST (NULL AS type-of-foo)
However, we allow unadorned NULL in other contexts as a shorthand for
the CAST notation, so it's inconsistent of us to say that in this
context it means something different.

The real problem with accepting this Microsoftism is that it's a trap
for unwary programmers.  Case 1: someone who's not studied SQL in detail
might experiment with examples involving "foo = NULL" and jump to
reasonable but entirely incorrect conclusions about how comparisons
involving NULL operate.  Case 2: someone who *has* studied SQL, and is
also aware that we accept unadorned NULLs, will also draw the wrong
conclusions about what this construct will do.  Bottom line: this kluge
surprises everyone except those who already know it exists.  I don't
like systems that surprise their users in inconsistent ways.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jean-Francois Leveque"
Date:
Subject: Need information about Foreign Key created Triggers
Next
From: Tom Lane
Date:
Subject: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards