Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers