From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Re: Comparisons on NULLs (was Re: A small problem...) |
Date: | 1998-11-04 05:22:16 |
Message-ID: | Pine.BSF.4.05.9811040120460.2139-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 3 Nov 1998, D'Arcy J.M. Cain wrote:
> Thus spake Tom Lane
> > >> but I can see the reasonableness of defining "3 != NULL" as TRUE.
> >
> > > Actually I see it as FALSE. That's what I was suggesting earlier. All
> > > comparisons to null should be false no matter what the sense of the
> > > test.
> >
> > Hmm. That yields extremely unintuitive results for = and !=. That is,
> >
> > SELECT * FROM t WHERE b = NULL;
> >
> > will never return any rows, even if there are some where b is null;
>
> Hmmm. That would be a problem. Of course, we could treat the null
> value at the higher level too. I guess that's why we have the "IS
> NULL" syntax in the first place. It is different than comparing the
> actual values.
>
> Marc, how long can we hold 6.4 while we work this all out?
How long can we hold *what*? Is this a new bug that didn't exist
in previous version of PostgreSQL?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 1998-11-04 05:59:14 | Re: [HACKERS] Re: Comparisons on NULLs (was Re: A small problem...) |
Previous Message | D'Arcy J.M. Cain | 1998-11-04 04:07:49 | Re: Comparisons on NULLs (was Re: A small problem...) |