Re: BUG #5974: UNION construct type cast gives poor error message
От | Tom Lane |
---|---|
Тема | Re: BUG #5974: UNION construct type cast gives poor error message |
Дата | |
Msg-id | 1516.1302738115@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5974: UNION construct type cast gives poor error message ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-bugs |
"Kevin Grittner" <Kevin.Grittner@wicourts.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
В списке pgsql-bugs по дате отправления: