-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Minor: return internal error rather than panic on unexpected error in COUNT DISTINCT #9712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| assert_eq!(states.len(), 1, "array_agg states must be singleton!"); | ||
| let array = &states[0]; | ||
| let list_array = array.as_list::<i32>(); | ||
| for inner_array in list_array.iter() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we just filter out Nones? just thinking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think filtering out nulls would potentially silently ignore errors
I think the rationale goes like
- This code is used to combine multiple partial results (the results of calling
Self::state()) - Since
Self::statenever returnsNone-- it always returnsOk(vec![ScalarValue::List(arr)])then this merge code should never receive aNone
comphead
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm thanks @alamb for explanation
Co-authored-by: comphead <comphead@users.noreply.github.com>
|
Thanks for the review @comphead |
Which issue does this PR close?
Follow on to #9679
Rationale for this change
@Omega359 pointed out that the use of
expectwould panic on unexpected results: #9679 (comment)What changes are included in this PR?
Change a panic into an internal error
Are these changes tested?
No (it is "impossible" to hit this code)
Are there any user-facing changes?
Better UX on unexpected error