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

From Zeugswetter Andreas SB
Subject AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Date
Msg-id 11C1E6749A55D411A9670001FA687963368310@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Tom Ivar Helbekkmo <tih@kpnQwest.no>)
Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Peter Eisentraut <peter_e@gmx.net>)
Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Tom Ivar Helbekkmo <tih@kpnQwest.no>)
Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > Yes, column = NULL should *never* return true according to the spec (it
> > should always return NULL in fact as stated).  The reason for breaking
> > with the spec is AFAIK to work with broken microsoft clients that seem to
> > think that =NULL is a meaningful test and generate queries using that.
> 
> Microsoft Access is the guilty party, IIRC.  I recently tried to stir up
> some interest in changing this behavior back to the standard, but
> apparently there are still too many people using broken versions of
> Access.

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).
If not it would simply be an extension to the standard with the defined
behavior of beeing identical to "column is null".

Andreas


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Wildcards in pg_dump
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Re: [PATCHES] Fw: Isn't pg_statistic a security hol e - Solution Proposal