fix: Avoid unnecessary type casts in concat_ws#20436
fix: Avoid unnecessary type casts in concat_ws#20436neilconway wants to merge 3 commits intoapache:mainfrom
concat_ws#20436Conversation
|
I did a quick look at the changes and nothing obvious jumped out at me. I'll try and find time to do a more extensive review if no one else beats me to it. |
|
@Omega359 Thank you! |
|
🤖 |
|
🤖: Benchmark completed Details
|
| builder.append_offset(); | ||
| continue; | ||
| match return_datatype { | ||
| DataType::Utf8View => { |
There was a problem hiding this comment.
I wonder if all this duplicated code could be eliminated with an approach similar to
?There was a problem hiding this comment.
Yeah, I think that would make sense to do. I'm inclined to do it as a follow-up PR -- let me know if you'd prefer it as part of this PR.
Which issue does this PR close?
Rationale for this change
concat_wsreturnedUtf8, regardless of the input types it was called with. If it was called withLargeUtf8, returningUtf8might overflow. In general, functions like these should operate on all three string representations unless there is a compelling reason not to (e.g., this is howconcatworks).simplify_concat_wsalways constructed new literals with typeUtf8. This lead to unnecessary casts when its inputs were of a different string type.What changes are included in this PR?
concat_wsreturn type matching its input types, following howconcatdoes it.simplify_concat_ws, construct literals with the right type, not alwaysUtf8return_typeforconcatto be more readableStringViewArrayBuilderAPI more similar to the other string array builders, WRT null handlingAre these changes tested?
Yes.
Are there any user-facing changes?
Yes: some queries involving
concat_wswill now omit unnecessary cast operations, and the return type ofconcat_wsmight be any of the three string types. Generally these changes should match user expectations better than the previous behavior.