mihailom-db commented on code in PR #45383:
URL: https://github.com/apache/spark/pull/45383#discussion_r1514266949
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/stringExpressions.scala:
##########
@@ -509,18 +509,10 @@ abstract class StringPredicate extends BinaryExpression
return checkResult
}
// Additional check needed for collation compatibility
- val rightCollationId: Int =
right.dataType.asInstanceOf[StringType].collationId
- if (collationId != rightCollationId) {
- DataTypeMismatch(
- errorSubClass = "COLLATION_MISMATCH",
- messageParameters = Map(
- "collationNameLeft" ->
CollationFactory.fetchCollation(collationId).collationName,
- "collationNameRight" ->
CollationFactory.fetchCollation(rightCollationId).collationName
- )
- )
- } else {
- TypeCheckResult.TypeCheckSuccess
- }
+ val outputCollationId: Int = TypeCoercion
Review Comment:
Have looked into it. The problem we have is the test in
`QueryCompilationErrorSuite`. We have 2 errors: `COLLATION_MISMATCH` and
`UNSUPPORTED_COLLATION.FOR_FUNCTION`. If someone calls a function with
different collations we run in to a problem which should be thrown first. Do we
first try to collate parameters and then check if function is supported for
that collation, or do we first throw an error that some collation is not
supported by the function? If I leave the check in `StringPredicate`, the
method `checkInputDataTypes` in super class is called first and we have
`COLLATION_MISMATCH` first, but if I change it to the rule, we have
`UNSUPPORTED_COLLATION.FOR_FUNCTION` first. The question is, which is better
for the customer?
--
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]
