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?

			regards, tom lane

In response to

• Re: behavior of ' = NULL' vs. MySQL vs. Standards at 2001-06-07 01:12:51 from Stephan Szabo

Responses

• Re: behavior of ' = NULL' vs. MySQL vs. Standards at 2001-06-07 03:12:46 from Stephan Szabo
• Re: behavior of ' = NULL' vs. MySQL vs. Standards at 2001-06-07 13:41:32 from Thomas Lockhart
• Re: behavior of ' = NULL' vs. MySQL vs. Standards at 2001-06-07 15:53:21 from Josh Berkus
• Re: [HACKERS] Re: behavior of ' = NULL' vs. MySQL vs. Standards at 2001-06-07 19:17:40 from Tom Ivar Helbekkmo

pgsql-hackers by date

Next:	From: Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=	Date: 2001-06-07 02:37:57
	Subject: Re: ORDER BY Problem...
Previous:	From: Christopher Kings-Lynne	Date: 2001-06-07 02:14:13
	Subject: RE: place for newbie postgresql hackers to work

pgsql-sql by date

Next:	From: Paul Tomblin	Date: 2001-06-07 02:26:01
	Subject: Help me speed things up...
Previous:	From: Tom Lane	Date: 2001-06-07 02:13:11
	Subject: Re: maximum number of rows in table - what about oid limits?