theirix commented on code in PR #22244:
URL: https://github.com/apache/datafusion/pull/22244#discussion_r3312620445
##########
datafusion/sqllogictest/test_files/spark/string/concat.slt:
##########
@@ -71,67 +72,22 @@ SELECT concat('a', arrow_cast('b', 'LargeUtf8'),
arrow_cast('c', 'Utf8View')), a
----
abc Utf8View
-# Test mixed types: Utf8 + Binary
-query TT
-SELECT concat(arrow_cast('hello', 'Utf8'), arrow_cast(' world', 'Binary')),
arrow_typeof(concat(arrow_cast('hello', 'Utf8'), arrow_cast(' world',
'Binary')));
-----
-hello world Utf8
+# Coercion rules from Binary to Utf8 do no apply compared to generic `concat`,
+# so `concat` produces an explicit error
+query error Error during planning: concat does not support mixed string and
binary inputs
+SELECT concat(arrow_cast('hello', 'Utf8'), arrow_cast(' world', 'Binary'));
Review Comment:
I just tried to build and test an old build (a few commits before #20787 -
e.g. 0383a88a1c0e0d338d9b0ca35128ce2bb4658d3c). If I introduce this simple
`select concat(x'1234', '1234')` to Spark SLT, it fails with "Concat function
does not support scalar type 1234". With this PR, it fails with "function does
not support mixed string and binary inputs". So it's consistent. The only
difference should be the null handling, if I'm not mistaken.
I am confused about why the Spark SLT is different from the `spark.sql`
calls above. Can you try again?
Regarding the PR scope, I thought about it, but it's not feasible. Spark UDF
reuses the majority of the general concat UDF. And we didn't have SLTs for
generic concat before, that's why I moved and adjusted tests for both functions.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
