xiedeyantu commented on code in PR #4706:
URL: https://github.com/apache/calcite/pull/4706#discussion_r2647300220


##########
core/src/main/java/org/apache/calcite/rex/RexSimplify.java:
##########
@@ -3034,6 +3038,71 @@ private static class VariableCollector extends 
RexVisitorImpl<Void> {
     }
   }
 
+  private static final Set<SqlKind> CONSTANT_VALUE_CONSTRUCTOR_KINDS =
+      EnumSet.of(
+          SqlKind.ARRAY_VALUE_CONSTRUCTOR,
+          SqlKind.MAP_VALUE_CONSTRUCTOR,
+          SqlKind.MULTISET_VALUE_CONSTRUCTOR);
+
+  private static @Nullable Pair<RexNode, RexNode> constantEquality(RexCall 
call) {
+    final RexNode o0 = call.getOperands().get(0);
+    final RexNode o1 = call.getOperands().get(1);
+    if (RexUtil.isReferenceOrAccess(o0, true) && isConstant(o1)) {
+      return Pair.of(o0, o1);
+    }
+    if (RexUtil.isReferenceOrAccess(o1, true) && isConstant(o0)) {
+      return Pair.of(o1, o0);
+    }
+    return null;
+  }
+
+  private static boolean constantsEquivalent(RexNode node1, RexNode node2) {
+    if (Objects.equals(node1, node2)) {
+      return true;
+    }
+    if (!(node1 instanceof RexCall) || !(node2 instanceof RexCall)) {
+      return false;
+    }
+    final RexCall call1 = (RexCall) node1;
+    final RexCall call2 = (RexCall) node2;
+    if (call1.getKind() != call2.getKind()) {
+      return false;
+    }
+    switch (call1.getKind()) {
+    case MULTISET_VALUE_CONSTRUCTOR:
+      return multisetLiteralEquals(call1, call2);
+    case MAP_VALUE_CONSTRUCTOR:
+      return mapLiteralEquals(call1, call2);
+    default:
+      return false;
+    }
+  }
+
+  private static boolean multisetLiteralEquals(RexCall left, RexCall right) {
+    return HashMultiset.create(left.getOperands())
+        .equals(HashMultiset.create(right.getOperands()));

Review Comment:
   Yes, we just discussed. The current goal is to implement a simplification, 
but it doesn’t seem very logical to skip sorting. Logically speaking, should we 
also add sorting in the previous PR? Or should we also avoid sorting in the 
current PR? If it depends on the dialect, that kind of calculation logic 
doesn’t seem very straightforward to implement. Would it be better to add 
sorting to the map in the previous PR?



-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to