Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> That said, there may also be merit in arguing that the spec is just
> broken on this point. I think back when IS NULL was originally changed
> to conform to the spec, it might have been better to just say "no,
> that's silly" and stick with the old behavior.
> We wouldn't strictly speaking be violating the spec if we did that,
> because we don't claim to support feature T051 "Row types", and so we
> can just say that our row types are a nonstandard extension without the
> standard IS NULL behavior. We do in fact violate the spec here in many
> ways; for example we treat types from CREATE TYPE foo AS (fields) as
> being row types, but in fact the spec says these are user-defined
> structured types and not row types.
> But whether it would be a good idea to actually revert to the old
> way... that's another question. Does anyone actually _want_ the spec
> behavior of IS [NOT] NULL?
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. I can't
find anything in the mail archives discussing it specifically, and it was
only a very minor element of that patch. I strongly suspect that Lockhart
just did what the spec said without thinking about it much; there is
certainly no trace of user requests for this behavior.
Later on we improved it to be less inconsistent with other ways of
specifying a rowtype argument, but again I don't see much indication of
user requests driving that, see here:
https://www.postgresql.org/message-id/flat/451BDB28.4050201%40sigaev.ru
But the other side of the coin is that the behavior does date back ten
years or more. Between backwards compatibility worries and the quite
clear language of the spec, it's a bit hard to summon the conviction to
say we ought to change it, much as I'd like to.
regards, tom lane