u70b3 opened a new pull request, #23723:
URL: https://github.com/apache/datafusion/pull/23723
## Which issue does this PR close?
- Closes #22208
- Closes #22193
Supersedes #22250 (closed unmerged by its author on 2026-06-04 after the
approach was approved). Note: both issues are currently assigned to @xiedeyantu
(idle since 2026-05; #22193 was explicitly blocked on #22250). I've left a note
on both issues; happy to coordinate if the assignee has work in progress.
## Rationale for this change
Two overflow bugs in the `generate_series` / `range` table functions, both
panicking in debug builds and silently wrapping in release:
1. **#22208** — integer series: `SELECT * FROM
generate_series(9223372036854775806, 9223372036854775807, 2)` panics with
`attempt to add with overflow` when advancing past `i64::MAX`. PostgreSQL and
DuckDB both return one row (`9223372036854775806`), stopping after the last
reachable value.
2. **#22193** — date series: converting `Date32` days to timestamp
nanoseconds uses an unchecked multiplication, so `generate_series(DATE
'0001-01-01', ...)` panics at planning time. Dates outside the nanosecond
timestamp range (1677-09-21 – 2262-04-11) cannot be represented and must error
cleanly instead.
## What changes are included in this PR?
- `datafusion/functions-table/src/generate_series.rs`
- `SeriesValue::advance` now takes `end: &mut Self`; the `i64`
implementation uses `checked_add` and, on overflow, clamps `end` so the series
terminates after the last reachable value (the approach approved in #22250).
The per-batch loop stops right after emitting the final value.
`TimestampValue::advance` already errors on out-of-range interval addition and
is unchanged apart from the signature.
- The Date32→nanoseconds conversion uses `checked_mul` and returns a
planning error naming the offending argument.
- `datafusion/sqllogictest/test_files/table_functions.slt`
- Regression cases: positive/negative step overflow, landing exactly on
`i64::MAX`, `range` (end-exclusive) overflow, and first/second date argument
out of range.
## Are these changes tested?
Yes:
- New sqllogictest cases (exact reproducers from both issues, plus boundary
variants); verified the integer-case outputs match PostgreSQL/DuckDB.
- Verified `cargo fmt`, workspace clippy
(`avro,integration-tests,extended_tests`, `-D warnings`), `cargo test -p
datafusion-functions-table`, and the extended workspace suite (ci profile with
`avro,json,backtrace,extended_tests,recursive_protection,parquet_encryption`) —
all green.
## Are there any user-facing changes?
Only the bug fixes: integer series near `i64::MAX`/`MIN` now return the
reachable values instead of panicking or wrapping (matching PostgreSQL/DuckDB),
and out-of-range dates produce a planning error instead of a panic. No API
changes.
--
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]
