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

I wrote:
> Good question.  The existing behavior seems to be traceable as far back as
> 68d9fbeb5511d846ce3a6f66b8955d3ca55a4b76, which implemented the specific
> syntax ROW( ... ) IS [NOT] NULL by dint of breaking the ROW construct into
> its field expressions and applying scalar NullTest to each one.

BTW, thinking about that a bit more, I'm pretty sure that back then we did
not have any robust notion of composite-type datums at all, and thus that
there simply would not have been any other way to implement this syntax.
It would not have worked to treat ROW(...) as a construct that delivered
a single Datum to a standard NullTest expression node.  So it was pretty
convenient for Lockhart that the spec was written the way it was.

Also note the observation in the 2006 thread that the N-scalar-NullTests
implementation didn't get the semantics quite right anyway, which makes it
even less likely that anybody was depending on the spec semantics between
2002 and 2006.

But that still leaves us with ten years of history in which we *were*
conforming to the spec, modulo the very narrow corner case mentioned
in this thread.

            regards, tom lane