From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Gabor Csuri <gcsuri(at)coder(dot)hu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: I don't understand... |
Date: | 2001-05-22 15:21:13 |
Message-ID: | Pine.BSF.4.21.0105220815060.62173-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 21 May 2001, Gabor Csuri wrote:
> Hi All again,
>
> after I deleted the "null row" from carname:
> SELECT DISTINCT h_name
> FROM haszon
> WHERE h_name NOT IN (SELECT cn_name FROM carname)
>
> +---------------+
> | h_name |
> +---------------+
> | DAEWOO-FSO |
> | DAEWOO-LUBLIN |
> | GAZ |
> | TATA |
> +---------------+
> Query OK, 4 rows in set (0,13 sec)
>
> It's working now, but is it correct?
Yep. :(
SQLs NULLs give lots of pain and suffering.
NULL is an unknown value, so you can know
that there *IS* a matching row, but you
never know with certainty that there *ISN'T*
a matching row when a NULL is involved.
Basically IN says, if row1=row2 is true for
any row, return true; if row1=row2 is false
for every row return false; otherwise return
NULL. When it gets to the comparison with
the NULL, row1=row2 gives a NULL not a false,
so the IN returns NULL (which won't get
through the where clause).
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2001-05-22 17:11:50 | Re: AW: Plans for solving the VACUUM problem |
Previous Message | Ross J. Reedstrom | 2001-05-22 14:43:40 | Re: Re: I don't understand... |