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)