github-actions[bot] commented on code in PR #68488:
URL: https://github.com/apache/doris/pull/68488#discussion_r4095083422
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/NumericArithmetic.java:
##########
@@ -277,7 +277,7 @@ public static Expression divideDouble(DoubleLiteral first,
DoubleLiteral second)
*/
@ExecFunction(name = "divide")
public static Expression divideDecimal(DecimalLiteral first,
DecimalLiteral second) {
- if (first.getValue().compareTo(BigDecimal.ZERO) == 0) {
+ if (second.getValue().compareTo(BigDecimal.ZERO) == 0) {
Review Comment:
[P2] Complete DECIMAL folding parity for nonzero quotients too. This is
distinct from the resolved zero-divisor case: `percentile_reservoir(number,
cast(1 as decimalv2(27,9)) / cast(3 as decimalv2(27,9)))` reaches this helper,
whose nonzero branch uses exact `BigDecimal.divide`; it throws,
`ExpressionEvaluator` returns the original `Divide`, and the new legality check
rejects it as "not a constant". `1 / 1024` similarly produces a scale-10 value
that the inferred scale-9 literal rejects. BE evaluates these at scale 9 with
rounding (`0.333333333` / `0.000976563`), so valid levels remain rejected on
plain/window/INSERT/state/combine paths even with `debug_skip_fold_constant`;
the parallel DecimalV3 helper has the same exact-division gap. Please use
BE-equivalent scale/rounding while preserving the analyzed type, then cover
these cases.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
