From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, 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 13:41:32 |
Message-ID: | 3B1F848C.CAA0F438@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
> > 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.
Since according to the standard "column = NULL" is a near-useless
construct (equivalent to "FALSE") it does not seem to pollute the
grammar much to allow an M$ compatible interpretation. I was not happy
having it added (much better to ask that responsive, customer-focused
company to fix their language compliance) but now that it is there it
seems to be an isolated and manageable feature.
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | D. Hageman | 2001-06-07 13:50:14 | Re: Any time estimates for 7.1.2 RPM's ? |
Previous Message | Zeugswetter Andreas SB | 2001-06-07 13:21:22 | AW: AW: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL v s. S tand ards |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Stosberg | 2001-06-07 14:40:40 | Re: behavior of ' = NULL' vs. MySQL vs. Standards |
Previous Message | Jonathan Bartlett | 2001-06-07 13:34:24 | Re: maximum number of rows in table - what about oid limits? |