Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL
От | David G. Johnston |
---|---|
Тема | Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL |
Дата | |
Msg-id | CAKFQuwZ68VbKkTjugYMxL=ktpvc64_mtf3Reabby2Br9jNndzg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14235: inconsistencies with IS NULL / IS NOT NULL (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: