Re: Re: I don't understand...

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).

In response to

Browse pgsql-hackers by date

  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...