You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@calcite.apache.org by GitBox <gi...@apache.org> on 2020/11/12 09:43:15 UTC

[GitHub] [calcite] danny0405 commented on a change in pull request #2246: [CALCITE-4377] Fix the return nullability inference during rex simpli…

danny0405 commented on a change in pull request #2246:
URL: https://github.com/apache/calcite/pull/2246#discussion_r521969779



##########
File path: core/src/main/java/org/apache/calcite/rex/RexSimplify.java
##########
@@ -900,13 +902,12 @@ private void validateStrongPolicy(RexNode rexNode) {
     case ANY:
       List<RexNode> operands = ((RexCall) rexNode).getOperands();
       if (rexNode.getType().isNullable()) {
-        assert operands.stream()
-            .map(RexNode::getType)
-            .anyMatch(RelDataType::isNullable);
+        // Ignores the nullability change when all the operands are literals
+        // which come from the simplification.
+        assert operands.stream().map(RexNode::getType).anyMatch(RelDataType::isNullable)
+            || operands.stream().allMatch(p -> RexUtil.isLiteral(p, false));

Review comment:
       During the simplification, we drop the useless case `cast(1 as nullable INT)` which breaks the nullability. We have 2 choices:
   1. Do not make any simplification that breaks the nullability
   2. Make the validation strategy more relaxed
   
   I choose the latter.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org