"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I'm not sure the spec requires *any* of them to work.
It doesn't. NULL in the standard is not part of the generic expression
syntax; it only appears as <implicitly typed value specification> (which
lets it be the direct argument of CAST, or the DEFAULT value for a table
column) and as <contextually typed value specification> (which lets it
be an INSERT or UPDATE's direct source value). So far as I can see,
these are the only contexts where a NULL literal is allowed in SQL99.
The syntax rule for a NULL literal is interesting too:
2) The declared type DT of a <null specification> NS is determined
by the context in which NS appears. NS is effectively replaced
by CAST ( NS AS DT ).
NOTE 70 - In every such context, NS is uniquely associated with
some expression or site of declared type DT, which thereby
becomes the declared type of NS.
The NOTE makes it pretty clear that this is intentional and not some
sort of omission. I have not tried to trace the syntax productions to
verify that this is still true in SQL:2008 (mainly because I don't have
an easily greppable copy of that standard) but I see that the above text
is still there in 6.5 <contextually typed value specification>.
In short: the standard disallows an un-cast NULL in a SELECT's targetlist
a priori, let alone one in a SELECT that's an arm of a set operation.
I doubt we want to copy that ...
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Robert Haas||Date: 2011-04-14 01:19:47|
|Subject: Re: BUG #5856: pg_attribute.attinhcount is not correct.|
|Previous:||From: Tom Lane||Date: 2011-04-13 23:26:06|
|Subject: Re: BUG #5974: UNION construct type cast gives poor error message |