Re: [HACKERS] A small problem with the new inet and cidr typesg - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] A small problem with the new inet and cidr typesg
Date
Msg-id 6914.910107974@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] A small problem with the new inet and cidr typesg  (darcy@druid.net (D'Arcy J.M. Cain))
Responses Re: [HACKERS] A small problem with the new inet and cidr typesg  (darcy@druid.net (D'Arcy J.M. Cain))
List pgsql-hackers
darcy@druid.net (D'Arcy J.M. Cain) writes:
> you do realize that this wouldn't work anyway, right?  The following
> is a parse error.

>     SELECT count(*) FROM t1 WHERE b = null;

> Mind you, I think that's a weakness but I don't know what the issues
> are with respect to the code or the standard.

I believe the accepted spelling of that query is
     SELECT count(*) FROM t1 WHERE b IS NULL;

(or IS NOT NULL).  I don't know either what the SQL standard has to say
about the issue --- does it expect "= NULL" to be a synonym for "IS NULL"?

The CREATE FUNCTION example does seem to illustrate that it'd be nice
if "=" and "!=" worked on NULL values.  I'd still object to trying
to define an order that includes NULL, so "3 < NULL" should return NULL,
but I can see the reasonableness of defining "3 != NULL" as TRUE.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] A small problem with the new inet and cidr types
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Re: [HACKERS] A small problem with the new inet and cidr typesg