geoffreyclaude opened a new pull request, #26095:
URL: https://github.com/apache/datafusion/pull/26095
## Which issue does this PR close?
No existing issue. The SQL regression below reproduces the bug on current
main.
## Rationale for this change
BIT_XOR returns 0 instead of NULL after the last non-null value leaves a
sliding window. For values 7, NULL, 9, a window containing only the preceding
row produces NULL, 7, 0; the correct results are NULL, 7, NULL.
```sql
SELECT id,
bit_xor(v) OVER (
ORDER BY id ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING
) AS x
FROM (VALUES (1, CAST(7 AS BIGINT)),
(2, CAST(NULL AS BIGINT)),
(3, CAST(9 AS BIGINT))) AS t(id, v)
ORDER BY id;
```
## What changes are included in this PR?
Add a sliding BIT_XOR accumulator that tracks the remaining non-null count
alongside the XOR value. This distinguishes an empty aggregate from a nonempty
aggregate whose values cancel to zero.
The sliding factory supplies this accumulator. The ordinary accumulator no
longer advertises retraction support. Ordinary scalar and grouped aggregation
retain their existing one-field state and groups implementation.
## What is the testing strategy for this PR?
The public-factory regression fails on unmodified main and passes with the
fix. Six focused tests cover removing the final non-null value, valid zero,
empty-state reuse, merged intermediate counts, and ordinary/DISTINCT state and
capabilities.
The new bit_xor_sliding_window.slt exercises all eight integer types across
batch-size-2 boundaries, empty and all-null frames, ordinary GROUP BY, and
existing DISTINCT/Null-input behavior.
Passed:
- `cargo fmt --all`
- `cargo clippy --all-targets --all-features -- -D warnings`
- The extended workspace test command from `AGENTS.md`: 12,449 Rust tests
passed, 8 existing tests ignored, and all 528 SQL files completed, including
all 125 extended fuzz cases.
- `./dev/rust_lint.sh`, including its Clippy feature set, generated docs,
license checks, dependency checks, Rustdoc with warnings denied, and the HTML
documentation build.
The extended test run used a subprocess open-file limit of 65,536. At the
environment's default limit of 1,024, an unrelated sort spill test hit `Too
many open files`; that same unchanged test and the complete suite passed with
the raised limit.
## Are there any user-facing changes?
Sliding BIT_XOR windows return NULL after all non-null inputs leave. Callers
that need retraction should request the sliding accumulator; the ordinary
factory reports that it does not support retraction.
--
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]