alexandrefimov commented on issue #25043:
URL: https://github.com/apache/datafusion/issues/25043#issuecomment-6010598433
Additional execution case from a SQL producer: DuckDB 1.5.5 with the
extension at DuckDB PR 302 head `a454a7c` (unreleased) exports this query as
standard decimal `add` with output `decimal(38,6)` and `overflow: [ERROR]`:
```sql
CREATE TABLE overflow38 (a DECIMAL(38,6), b DECIMAL(38,6));
INSERT INTO overflow38 VALUES
(99999999999999999999999999999999.999999, 0.000001);
CALL get_substrait_json('SELECT a+b AS r FROM overflow38');
```
DataFusion main `bd8619015` accepts the exported plan and returns
`100000000000000000000000000000000.000000` as `Decimal128(38,6)`. Arrow's
`validate_decimal_precision(38)` rejects that value. Negative overflow behaves
the same; the adjacent in-range value and precision-18 overflow control pass.
Native DataFusion SQL also returns the out-of-range value.
The original report omitted overflow options. This case explicitly selects
ERROR, which the [option
contract](https://github.com/substrait-io/substrait/blob/v0.102.0/site/docs/expressions/scalar_functions.md#options)
requires the consumer to honor or reject. The default `from_scalar_function`
maps `add` to a `BinaryExpr` without handling `f.options`.
Can this case be included in the current fix, or should explicit-option
handling be tracked separately?
--
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]
