Repository navigation
fix: reject DISTINCT in corr, covar and regr_* instead of ignoring it - #26484
Conversation
| SELECT covar_pop(x, y), covar_pop(DISTINCT x, y) FROM (VALUES (1.0, 1.0), (1.0, 1.0), (2.0, 3.0)) t(x, y) | ||
|
|
||
| statement error DataFusion error: This feature is not implemented: REGR_COUNT\(DISTINCT\) aggregations are not available | ||
| SELECT regr_count(x, y), regr_count(DISTINCT x, y) FROM (VALUES (1.0, 1.0), (1.0, 1.0), (2.0, 3.0)) t(x, y) |
There was a problem hiding this comment.
nit: could you add a window case too? f(DISTINCT ..) OVER (...) reaches the check through create_sliding_accumulator rather than accumulator, so a test keeps that path covered if one of these functions ever overrides it. I checked locally that both of these already fail with the new error:
statement error DataFusion error: This feature is not implemented: CORR\(DISTINCT\) aggregations are not available
SELECT corr(DISTINCT x, y) OVER () FROM (VALUES (1.0, 1.0), (1.0, 1.0), (2.0, 3.0)) t(x, y)
statement error DataFusion error: This feature is not implemented: REGR_SLOPE\(DISTINCT\) aggregations are not available
SELECT regr_slope(DISTINCT x, y) OVER () FROM (VALUES (1.0, 1.0), (1.0, 1.0), (2.0, 3.0)) t(x, y)There was a problem hiding this comment.
Added both window cases, thanks for checking them.
| // The accumulator rejects `DISTINCT` with `not_impl_err!`, so the | ||
| // planner has to deduplicate the input first. |
There was a problem hiding this comment.
nit: the planner only removes DISTINCT here when SingleDistinctToGroupBy applies, which needs a single distinct field like corr(DISTINCT x, x). Every other case now fails. Maybe word it like this (same for the copies in covariance.rs and regr.rs):
- // The accumulator rejects `DISTINCT` with `not_impl_err!`, so the
- // planner has to deduplicate the input first.
+ // The accumulator rejects `DISTINCT` with `not_impl_err!`. It only
+ // works when the planner removes it first (`SingleDistinctToGroupBy`
+ // for a single distinct field, e.g. `corr(DISTINCT x, x)`).There was a problem hiding this comment.
Done, reworded in all four places, with each function's own name in the example.
jayzhan211
left a comment
There was a problem hiding this comment.
Thanks @abp002 , overall LGTM
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #26484 +/- ##
==========================================
+ Coverage 82.89% 82.92% +0.03%
==========================================
Files 1154 1154
Lines 458022 457885 -137
Branches 458022 457885 -137
==========================================
+ Hits 379683 379717 +34
+ Misses 55303 55141 -162
+ Partials 23036 23027 -9 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Thank you for opening this pull request! Reviewer note: cargo-semver-checks reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch). Details |
Which issue does this PR close?
corr,covar_pop,covar_sampandregr_*silently ignoreDISTINCT#26471.Rationale for this change
corr,covar_pop,covar_sampand theregr_*functions return the same result withDISTINCTas without it, because their accumulators never readis_distinct.What changes are included in this PR?
Their accumulators now return a not implemented error for
DISTINCT, asstddevandapprox_medianalready do.corr(DISTINCT x, x)still works, sinceSingleDistinctToGroupByrewrites it before it reaches the accumulator.What is the testing strategy for this PR?
New cases in
aggregate.slt. The twoREGR_COUNT(DISTINCT ...)results ineliminate_join_distinct.sltwere the non-distinct counts, so they now expect the error.Are there any user-facing changes?
These queries now fail with an error instead of returning a wrong result.