Merlin Moncure <mmoncure@gmail.com> writes:
> Not sure we are guided there. Currently we follow the spec
> specifically with the IS NULL operator but not in other cases.
Yeah. ExecEvalNullTest() has been taught about this, but most other
places that check null-ness just check overall datum null-ness without
any concern for composite types. This is a stopgap situation, obviously.
> The basic problem we have is that in postgres the record variable is a
> distinct thing from its contents and the spec does not treat it that
> was. For my part, I think the spec is totally out to lunch on this
> point but we've been stuck with the status quo for quite some time now
> -- there's been no compelling narrative that suggests how things
> should be changed and to what.
I tend to agree that the spec is poorly designed on this point.
Some reasons:
* Per spec, a partly-null row value does not satisfy either IS NULL or
IS NOT NULL. This at least fails to be non-astonishing. Worse: as
implemented in ExecEvalNullTest, a zero-column row satisfies *both*
IS NULL and IS NOT NULL. The SQL committee would no doubt argue that
that's not their problem because they disallow zero-column rows, but
it's still an indication that the behavior isn't well-designed.
* What about other container types? If ROW(NULL,NULL) IS NULL, should
it not also be the case that ARRAY[NULL,NULL] IS NULL? Then we'd also
have to think about range types, JSON, etc. That way madness lies.
Anyway it seems pretty bogus to claim that ARRAY[NULL,NULL] IS NULL,
because it has for example well-defined dimensions. You could maybe try
to justify treating the case differently because such an array value has
metadata, ie dimensions, in addition to its element values --- but I deny
the claim that a row value lacks any metadata.
So personally I'd much prefer to consider that ROW(NULL, NULL) isn't NULL,
and I'm not in a hurry to propagate ExecEvalNullTest's behavior to other
places.
The question of whether we should allow NOT NULL constraints on a datatype
is somewhat independent of that, though.
regards, tom lane