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

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> 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.

 Tom> I don't offhand recall any such complaints on pgsql-bugs.  Maybe
 Tom> there have been some on IRC.

Indeed so.

As an aside, while looking back through logs I found this, which was
reported as bug #7808 in 2013 and is still unfixed:

postgres=# select * from unnest(array[row('a',1)::c1,null::c1]) u;
ERROR:  function returning set of rows cannot return null value

(it came up in the context of a "how to strip nulls from an array"
question; array(select u from unnest(a) u where u is not null) obviously
works only for scalars, and you need not (u is null) instead.)

 >> Is there a single reported case where anyone has actually needed the
 >> spec's version of (x IS NOT NULL) for a composite type?

 Tom> By definition, we get no "reports" for a case where something
 Tom> works as someone expects.  So you're demanding proof that cannot
 Tom> exist.

I meant "reported" in a more general sense that bug reports, obviously.

--
Andrew (irc:RhodiumToad)