mihaibudiu commented on code in PR #4031:
URL: https://github.com/apache/calcite/pull/4031#discussion_r1828633929
##########
arrow/src/main/java/org/apache/calcite/adapter/arrow/ArrowTranslator.java:
##########
@@ -170,11 +170,47 @@ private String translateBinary(String op, String rop,
RexCall call) {
case CAST:
// FIXME This will not work in all cases (for example, we ignore string
encoding)
return translateBinary2(op, ((RexCall) left).operands.get(0), right);
+ case PLUS:
+ case MINUS:
+ right = translateArithmeticOp(left, right);
+ return translateBinary2(op, ((RexCall) left).operands.get(0), right);
default:
return null;
}
}
+ /**
+ * Translates a call to an arithmetic operator.
+ * This method handles arithmetic operations like addition and subtraction
+ * between literals and adjusts the right operand accordingly.
+ *
+ * @param left The left operand, which is an arithmetic operation
+ * @param right The right operand, which is a literal
+ * @return A new RexNode representing the adjusted right operand
+ */
+ private RexNode translateArithmeticOp(RexNode left, RexNode right) {
+ RexNode leftOperand = ((RexCall) left).operands.get(1);
Review Comment:
That is incorrect, the RelOptRules are designed to work for all dialects.
A Calcite-based compiler will have a parser, a converter, an optimizer, and
a back-end.
The job of doing optimizations belongs to the optimizer, not to the back-end.
If you put optimizations in the back-end, you have to reimplement them for
every target.
--
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]
