[
https://issues.apache.org/jira/browse/CALCITE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637260#comment-16637260
]
Zoltan Haindrich commented on CALCITE-2606:
-------------------------------------------
That sounds good; then that will also ensure that during opening a case
statement all branches must be ensured to be in sync with the result type.
> Return type inference for and/or may identify result type incorrectly
> ---------------------------------------------------------------------
>
> Key: CALCITE-2606
> URL: https://issues.apache.org/jira/browse/CALCITE-2606
> Project: Calcite
> Issue Type: Bug
> Reporter: Zoltan Haindrich
> Assignee: Zoltan Haindrich
> Priority: Major
>
> In case in an AND expression a null constant appears earlier than a nullable
> boolean; the return type is set to NULL instead of boolean.
> https://github.com/apache/calcite/blob/c39bfaa02a06ac91575076a6e74f29863923f5eb/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L198
> The problem can be reproduced; however I'm not sure if it would happen
> naturally or not - I've discovered it during enhancing case simplification.
> {code}
> @Test
> public void testUsageOfConstantNull() {
> RexLiteral constantNull = rexBuilder.constantNull();
> RexNode node1 = or(constantNull, vBool());
> assertThat(node1.getType(), is(vBool().getType()));
> RexNode node2 = or(vBoolNotNull(), constantNull);
> assertThat(node2.getType(), is(vBool().getType()));
> RexNode node3 = or(constantNull, constantNull);
> assertThat(node3.getType(), is(constantNull.getType()));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)