>>>>> "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)
