[ 
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)

Reply via email to