You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Vladimir Sitnikov (JIRA)" <ji...@apache.org> on 2018/09/16 17:28:00 UTC

[jira] [Created] (CALCITE-2563) Suspicious code in org.apache.calcite.rel.rules.AbstractMaterializedViewRule.EquivalenceClasses#addEquivalenceClass

Vladimir Sitnikov created CALCITE-2563:
------------------------------------------

             Summary: Suspicious code in org.apache.calcite.rel.rules.AbstractMaterializedViewRule.EquivalenceClasses#addEquivalenceClass
                 Key: CALCITE-2563
                 URL: https://issues.apache.org/jira/browse/CALCITE-2563
             Project: Calcite
          Issue Type: Bug
          Components: core
    Affects Versions: 1.17.0
            Reporter: Vladimir Sitnikov
            Assignee: Julian Hyde


https://github.com/apache/calcite/blob/323200507b72fec152e2f557b3f7f2209a042fe4/core/src/main/java/org/apache/calcite/rel/rules/AbstractMaterializedViewRule.java#L2542

{code:java}
      Set<RexTableInputRef> c1 = nodeToEquivalenceClass.get(p1);
      Set<RexTableInputRef> c2 = nodeToEquivalenceClass.get(p2);
      if (c1 != null && c2 != null) {
        // Both present, we need to merge
        if (c1.size() < c2.size()) {
          // We swap them to merge
          c1 = c2; // <-- HERE.  Should c1 and c2 be actually swapped?
          p1 = p2; // <-- What does this mean? p1 and p2 are not used. Should they be swapped as well just in case
        }
        for (RexTableInputRef newRef : c2) {
          c1.add(newRef);
          nodeToEquivalenceClass.put(newRef, c1);
        }
{code}

It looks like c1 vs c2 swap is missing, and a mere c1=c2 is used.
It would likely produce weird results.

/cc [~jcamachorodriguez]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)