From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Bhuvan A <bhuvansql(at)yahoo(dot)com> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: |
Date: | 2002-03-11 17:02:09 |
Message-ID: | 20020311085824.C45259-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, 11 Mar 2002, Bhuvan A wrote:
> > If you compare a NULL with anything you don't get a true value whether
> > you're comparing with =, !=, <, >, etc... That's how it's defined to
> > behave.
>
> where did you get this definition of behaviour!? is it applicable only to
> postgres or ..? its quite strange yaar!
It makes sense if you think of NULL as an unknown value. You don't know
if this unknown value is different from any particular value (even another
NULL). NULLs are one of the ugliest parts of SQL.
In case you're wondering for SQL92 (at least the draft I have), the
section is 8.2 <comparison predicate>, General Rules 1.
1) Let X and Y be any two corresponding <row value constructor
element>s. Let XV and YV be the values represented by X and Y,
respectively.
Case:
a) If XV or YV is the null value, then "X <comp op> Y" is un-
known.
From | Date | Subject | |
---|---|---|---|
Next Message | Mozilla at Marela | 2002-03-11 17:59:31 | Critical: Pgsql inserts bad timestamp (seconds 60.00) - causes failing of backup-restore |
Previous Message | Peter Eisentraut | 2002-03-11 16:46:31 | Re: |