Repository navigation
fix: support scalar string argument in native lpad/rpad #7450
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
base: main
Are you sure you want to change the base?
Changes from all commits
208b970
e0a5101
f913360
6161cfb
1f54ae0
b9ef2d7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -561,7 +561,7 @@ object CometRLike | |
| } | ||
|
|
||
| private object PadReasons { | ||
| val literalStrReason = "Scalar values are not supported for the `str` argument." | ||
| val literalStrReason = "Literal values are not supported for the `str` argument." | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Separately,
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good catch, thanks. I opened #7583 to track it, since it is a separate change from the scalar |
||
| val nonLiteralPadReason = "Only scalar values are supported for the `pad` argument." | ||
| } | ||
|
|
||
|
|
||
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.
Adding to the earlier comment about the expansion:
spark_read_side_padding_internalsizes its builder withdata_capacity.max(string_array.value_data().len()), so after the expansion a 1 MiB scalar over 64 rows also reserves at least 64 MiB of output, even whenrpad(..., 1)produces 64 bytes.One way to avoid both is for the loops in
spark_read_side_padding_internalto take the strings as an iterator plus theasciiflag and a capacity floor. The array arms would passstring_array.iter(),string_array.is_ascii()andvalue_data().len(), and this armstd::iter::repeat(string.as_deref()).take(n),string.is_ascii()and0. No expanded array is built, and the all-scalar case becomes the same loop withn = 1, so theto_array(1)andtry_from_arrayround trip at the end goes away. I have not tried it.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.
Thanks, done in 7c4f4ae. The padding loop now takes the strings as an iterator, an
asciiflag and a capacity floor. The array arms passstring_array.iter(),is_ascii()andvalue_data().len(), so their path is unchanged frommain. The scalar arm passesstd::iter::repeat_n(value, n),value.is_none_or(str::is_ascii)and0, so nothing is expanded and the output is not sized by the scalar.One part stays: when every argument is a scalar, the loop runs with
n = 1and builds a 1-row array, andtry_from_arrayturns it back into a scalar, since the result has to be a scalar there. Theto_array_of_sizehalf of the round trip is gone.