kosiew commented on code in PR #22306:
URL: https://github.com/apache/datafusion/pull/22306#discussion_r3295691981
##########
datafusion/functions/src/math/factorial.rs:
##########
@@ -139,14 +154,29 @@ const FACTORIALS: [i64; 21] = [
6402373705728000,
121645100408832000,
2432902008176640000,
-]; // if return type changes, this constant needs to be updated accordingly
+];
-fn compute_factorial(n: i64) -> Result<i64> {
+fn compute_factorial(n: i64) -> Result<i256> {
if n < 0 {
- exec_err!("factorial of a negative number is undefined")
- } else if n < FACTORIALS.len() as i64 {
- Ok(FACTORIALS[n as usize])
- } else {
- exec_err!("Overflow happened on FACTORIAL({n})")
+ return Ok(i256::from(1));
Review Comment:
I think this change accidentally introduced a behavioral regression for
negative inputs.
Previously, `factorial(-1)` returned an execution error with `factorial of a
negative number is undefined`, which matches both the documented behavior and
the existing PostgreSQL-compatible SLT coverage.
With the new branch returning `Ok(i256::from(1))`, negative factorials now
silently succeed with `1`.
`datafusion/sqllogictest/test_files/math.slt` still expects:
```sql
select factorial(-1);
```
to error, so this is probably the source of the CI failure mentioned in the
PR.
Could we restore the negative-input error path while keeping the new `i256`
/ Decimal256 overflow handling?
--
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]
