Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL
Date
Msg-id CAKFQuwZ68VbKkTjugYMxL=ktpvc64_mtf3Reabby2Br9jNndzg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Fri, Jul 22, 2016 at 8:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> > Yeah, but the main visible effect of that has been a stream of "you hav=
e
> > to use NOT (x IS NULL) rather than (x IS NOT NULL)" responses to people
> > having trouble with this.
>
> I don't offhand recall any such complaints on pgsql-bugs.  Maybe there
> have been some on IRC.
>
> > Is there a single reported case where anyone has actually needed the
> > spec's version of (x IS NOT NULL) for a composite type?
>
> By definition, we get no "reports" for a case where something works
> as someone expects.  So you're demanding proof that cannot exist.
>

Yeah, I'd say we lump this into the same bucket as "unintentional
correlated subqueries" and "forgot to add a where clause to your delete
statement".

In short, don't use "IS NOT NULL".  But, sorry, we cannot actually prohibit
it=E2=80=8B without upsetting lots of people.

David J.
=E2=80=8B

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL
Next
From: Andrew Gierth
Date:
Subject: Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL