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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)