Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL
Date: 2016-07-23 00:34:15
Message-ID: CAKFQuwZ68VbKkTjugYMxL=ktpvc64_mtf3Reabby2Br9jNndzg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Jul 22, 2016 at 8:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> > Yeah, but the main visible effect of that has been a stream of "you have
> > 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​ without upsetting lots of people.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2016-07-23 01:37:09 Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL
Previous Message Tom Lane 2016-07-23 00:22:28 Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL