[
https://issues.apache.org/jira/browse/CALCITE-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189646#comment-17189646
]
Julian Hyde commented on CALCITE-4219:
--------------------------------------
I propose that we return lists of nullable values, and consumers just know
which operands may be null. That's what we do today.
And also add javadoc to say that the list is never null but, depending on the
operator, some of the operands may be null.
> Clarify SqlCall#getOperandList() nullability
> --------------------------------------------
>
> Key: CALCITE-4219
> URL: https://issues.apache.org/jira/browse/CALCITE-4219
> Project: Calcite
> Issue Type: Sub-task
> Components: core
> Affects Versions: 1.25.0
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> {{getOperandList()}} is implemented by a number of different {{SqlCall}}
> sub-classes, and the list often includes null values.
> The implementation is typically {{return ImmutableNullableList.of(...}}
> However, {{getOperandList()}} is used a lot, and the code assumes that the
> resulting values are non-null. The same happens for {{SqlCall#operand(int)}}.
> The workaround is to declare {{getOperandList()}} and {{operand(int)}} to
> return non-nullable values (even though nulls are possible), and we could add
> suppressions at the side which returns {{ImmutableNullableList}}.
> The solution might be behind the lines of adding
> {{nonNullableOperand(int)}}-like methods that would return non-nullable
> values and throw meaningful errors in case the value turns out to be null.
> Another option might be to ensure all the fields are non-nullable (e.g.
> create dummy SqlNode for empty values).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
