Re: [HACKERS] Re: Comparisons on NULLs (was Re: A small problem...)

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

In response to

Responses

Browse pgsql-hackers by date

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