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