Omega359 commented on code in PR #13403:
URL: https://github.com/apache/datafusion/pull/13403#discussion_r1845190135
##########
datafusion/functions-nested/src/string.rs:
##########
@@ -251,20 +254,21 @@ impl ScalarUDFImpl for StringToArray {
Utf8 | LargeUtf8 => {
List(Arc::new(Field::new("item", arg_types[0].clone(), true)))
}
+ Utf8View => List(Arc::new(Field::new("item", Utf8, true))),
Review Comment:
> yes, indeed. is contrary also possible? also, isn't this the downstream
function's problem, not here?
True. However since few other functions return utf8vew (currently) it would
generally mean that at some point any system that chains functions (fairly
normal dataframe usage) the output is going to be utf8 anyways. I'm not against
adding it here at all, just being realistic as to what conversions are going to
happen in a lot of cases anyways.
We may want to create an epic to update all the functions such that the
output matches the input type (if input and output are string types) similar to
what we did for utf8view for input.
> ideally in #12622, utf8view would be run-time variant of utf8, same
logical type, so next function could choose on its own
Yes, that would be the case for input.
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
