[
https://issues.apache.org/jira/browse/CALCITE-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786759#comment-16786759
]
Stamatis Zampetakis commented on CALCITE-2901:
----------------------------------------------
I was not thinking of chaning the method's signature but rather changing the
way the type is created to something similar to the code below:
{code:java}
final RelDataType type = typeFactory.copyType(fieldList.get(0).getType());
{code}
> RexSubQuery.scalar needs to allow specifying a different nullability value
> instead of the hard coded "true" value
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2901
> URL: https://issues.apache.org/jira/browse/CALCITE-2901
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.18.0
> Reporter: Muhammad Gelbana
> Priority: Major
> Labels: beginner, easyfix, newbie
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> The RexSubQuery.scalar(RelNode rel) method creates a subquery node with a
> hard coded nullability value of *true*, which might not be always valid.
> {code:java}
> public static RexSubQuery scalar(RelNode rel) {
> final List<RelDataTypeField> fieldList = rel.getRowType().getFieldList();
> assert fieldList.size() == 1;
> final RelDataTypeFactory typeFactory = rel.getCluster().getTypeFactory();
> final RelDataType type =
> typeFactory.createTypeWithNullability(fieldList.get(0).getType(),
> true);
> return new RexSubQuery(type, SqlStdOperatorTable.SCALAR_QUERY,
> ImmutableList.of(), rel);
> }
> {code}
> I prupose a slight change which is to update the method's signature to accept
> a boolean flag to specify the nullability of the subquery's type. Alongside
> an overloading method calls the modified one with the hard coded *true*
> nullability for backward compatibility.
> Please tell me if such change is acceptable so I can do it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
