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