| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | elein <elein(at)varlena(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, George Pavlov <gpavlov(at)mynewplace(dot)com>, pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: "large" IN/NOT IN subqueries result in query returning wrong data |
| Date: | 2005-12-28 15:47:33 |
| Message-ID: | 878xu55ilm.fsf@stark.xeocode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
elein <elein(at)varlena(dot)com> writes:
> > Note that the above are not inverses because you changed the lefthand
> > input. You do get consistent results when you just add or omit NOT:
> Yes, you are right. I skipped the permutations to get down to the point.
Remember that NULL means "unknown". So "1 IN (1,2,NULL)" *should* be true
because regardless of what that unknown value is it's still obvious that 1
really is in the list. And "3 NOT IN (1,2,NULL)" is unknown because it depends
on whether that unknown quantity is 3 or not.
IN is the same as "= ANY" so "1 IN (1,2,NULL)" is the same as
"1=1 OR 1=2 OR 1=NULL" which is true even though the last of the three is null.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-12-28 15:48:25 | Re: Cursors and recursion |
| Previous Message | J Crypter | 2005-12-28 15:28:23 | instead of trigger in pg |