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

Re: [HACKERS] Severe SUBSELECT bug in 6.5 CVS

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Bitmead <chris(dot)bitmead(at)bigfoot(dot)com>, pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] Severe SUBSELECT bug in 6.5 CVS
Date: 1999-06-26 18:55:03
Message-ID: 199906261855.OAA20214@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Chris Bitmead <chris(dot)bitmead(at)bigfoot(dot)com> writes:
> > httpd=> select * from a where i not in (select i from b);
> > [ returns nothing if b contains any nulls in column i ]
> 
> Of course, what's happening here is that the NOT IN is (in effect)
> transformed to
> 	a.i != b.i1 AND a.i != b.i2 AND a.i != b.i3 ...
> (writing i1, i2, ... for the values extracted from b).  Then, since
> any comparison involving NULL returns FALSE, the where-clause fails
> for all values of a.i.
> 
> I think this actually is a bug, not because it's wrong for "x != NULL"
> to be false, but because the SQL spec defines "a NOT IN t" as equivalent
> to "NOT (a IN t)".  IN is implemented as
> 	a.i = b.i1 OR a.i = b.i2 OR a.i = b.i3 ...
> which will effectively ignore nulls in b --- it'll return true if and
> only if a.i matches one of the non-null values in b.  Our implementation
> fails to maintain the equivalence that NOT IN is the negation of this.
> 
> It appears to me that to follow the SQL spec, a NULL found in a.i
> should return NULL for both IN and NOT IN (the spec appears to say that
> the result of IN is "unknown" in that case, and we are using NULL to
> represent "unknown"):

I would be interested to see how other databases handle this.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1999-06-26 18:57:17
Subject: Re: [HACKERS] regression bigtest needs very long time
Previous:From: Tom LaneDate: 1999-06-26 17:27:59
Subject: Re: [HACKERS] regression bigtest needs very long time

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