Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Standards

Interesting - my experience is that Access, at least, generally treats
NULL's correctly:

(This was done under Access 2000):
create table foo (name text(20))
insert into foo values ("bar");
insert into foo values ("bar");
insert into foo values ("bar");
insert into foo values ("bar");
insert into foo values (NULL);
insert into foo values (NULL);
insert into foo values (NULL);
insert into foo values (NULL);


select count(*) from foo where name=NULL;
returns 0

select count(*) from foo where name is null;
returns 4

select count(*) from foo where name <> "bar";
returns 0

Cheers,
Andy

---------------------------------------------------------  Andrew J. Perrin - Assistant Professor of Sociology
Universityof North Carolina, Chapel Hill
 
269 Hamilton Hall CB#3210, Chapel Hill, NC 27599-3210 USA  andrew_perrin@unc.edu - http://www.unc.edu/~aperrin

On Thu, 7 Jun 2001, Mark Stosberg wrote:

> Stephan Szabo wrote:
> > 
> > On Wed, 6 Jun 2001, Tom Lane wrote:
> > 
> > > Stephan Szabo <sszabo@megazone23.bigpanda.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.
> 
> > I'd rather have the default be the spec correct behavior
> > and let people configure their server to follow the misinterpretation.
> 
> I like that idea as well. Someone like me who didn't know that this
> feature was in there for M$ could have assumed it _was_ standard
> behavior, and started using it as a habit. Then when I started porting
> my code to another database, I'd have an extra surprise in for me. :) 
> 
> Rather than being an option targeted at just this piece of grammer,
> perhaps it could a piece of a potentially larger option of "stricter
> standards compliance." I realize there are a number of useful extensions
> to the SQL standard in Postgres (which I like and use.), but it seems
> like there would be uses for minimizing non-standard behavior, as well. 
> 
> Thank you all for your contributions to Postgres-- I use it everyday. :) 
> 
>   -mark
> 
> http://mark.stosberg.com/
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>