Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-1526

Use Strong to infer whether a predicate's inputs may be null

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.11.0
    • Component/s: None
    • Labels:
      None

      Description

      RexImplicationChecker must use Strong to infer whether a predicate's inputs may be null. In particular the code in RexImplicationChecker.implies2.

      Also RelMdPredicates.projectPredicate.

      Jesus Camacho Rodriguez, Could/should RexUtil.ExprSimplifier be using Strong?

      Also, maybe, RexUtil.simplifyIs.

      Also, LogicVisitor might be able to deduce that an expression is never null if certain input fields are not null.

        Issue Links

          Activity

          Hide
          julianhyde Julian Hyde added a comment -

          Resolved in release 1.11.0 (2017-01-11).

          Show
          julianhyde Julian Hyde added a comment - Resolved in release 1.11.0 (2017-01-11).
          Hide
          julianhyde Julian Hyde added a comment -

          The above fix introduced some regressions. Finally fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/cd806089.

          Show
          julianhyde Julian Hyde added a comment - The above fix introduced some regressions. Finally fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/cd806089 .
          Show
          julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/584432ca .
          Hide
          julianhyde Julian Hyde added a comment -

          Agreed, probably no immediate benefit. But currently we have redundant code (similar looking switch statements) and at future they will diverge. After they've diverged, and one of them has been refactored, we may no longer be able to combine them. Classic technical debt.

          Show
          julianhyde Julian Hyde added a comment - Agreed, probably no immediate benefit. But currently we have redundant code (similar looking switch statements) and at future they will diverge. After they've diverged, and one of them has been refactored, we may no longer be able to combine them. Classic technical debt.
          Hide
          jcamachorodriguez Jesus Camacho Rodriguez added a comment -

          RexUtil.ExprSimplifier traverses the expression and simplifies it, choosing whether to recognize UNKNOWN as FALSE depending on 1) the initial value for _ unknownAsFalseCall_, and 2) the expressions found in the traversal.

          Julian Hyde, I think it could be extended to use Strong indeed, by checking whether a subexpression might produce UNKNOWN and choosing accordingly the simplify method to call in RexUtil. However, I am still doubting whether that would help to detect further simplification opportunities, or it would just help simplifying/unifying the different code paths.

          Show
          jcamachorodriguez Jesus Camacho Rodriguez added a comment - RexUtil.ExprSimplifier traverses the expression and simplifies it, choosing whether to recognize UNKNOWN as FALSE depending on 1) the initial value for _ unknownAsFalseCall_, and 2) the expressions found in the traversal. Julian Hyde , I think it could be extended to use Strong indeed, by checking whether a subexpression might produce UNKNOWN and choosing accordingly the simplify method to call in RexUtil. However, I am still doubting whether that would help to detect further simplification opportunities, or it would just help simplifying/unifying the different code paths.

            People

            • Assignee:
              julianhyde Julian Hyde
              Reporter:
              julianhyde Julian Hyde
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development