Skip site navigation (1) Skip section navigation (2)

Re: behavior of ' = NULL' vs. MySQL vs. Standards

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Stosberg <mark(at)summersault(dot)com>, pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: behavior of ' = NULL' vs. MySQL vs. Standards
Date: 2001-06-07 03:12:46
Message-ID: Pine.BSF.4.21.0106062007340.18894-100000@megazone23.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-sql
On Wed, 6 Jun 2001, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > 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.
> 
> A compromise answer might be to offer a SET variable that selects the
> Microsoft-compatible misimplementation.  Would that fly?

It would for me.  I'd rather have the default be the spec correct behavior
and let people configure their server to follow the misinterpretation.
Is the conversion just the hack in the grammar rules for 
a_expr '=' a_expr?



In response to

Responses

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2001-06-07 03:43:36
Subject: Any time estimates for 7.1.2 RPM's ?
Previous:From: Hannu KrosingDate: 2001-06-07 03:09:18
Subject: Re: ORDER BY Problem...

pgsql-sql by date

Next:From: Gerald GutierrezDate: 2001-06-07 06:10:35
Subject: Are SQL commands "atomic" ?
Previous:From: Paul TomblinDate: 2001-06-07 02:26:01
Subject: Help me speed things up...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group