u70b3 commented on code in PR #23704:
URL: https://github.com/apache/datafusion/pull/23704#discussion_r3612138820
##########
datafusion/optimizer/src/analyzer/type_coercion.rs:
##########
@@ -442,6 +442,31 @@ impl<'a> TypeCoercionRewriter<'a> {
Ok(e)
}
+
+ /// Coerce the value and pattern expressions of a string pattern matching
+ /// expression (`LIKE`, `ILIKE` or `SIMILAR TO`) to a common type using
+ /// the provided coercion rules.
+ fn coerce_like_operands(
+ &self,
+ expr: Expr,
+ pattern: Expr,
+ coercion: fn(&DataType, &DataType) -> Option<DataType>,
+ op_name: &str,
+ ) -> Result<(Box<Expr>, Box<Expr>)> {
+ let left_type = expr.get_type(self.schema)?;
+ let right_type = pattern.get_type(self.schema)?;
+ let coerced_type = coercion(&left_type, &right_type).ok_or_else(|| {
+ plan_datafusion_err!(
+ "There isn't a common type to coerce {left_type} and
{right_type} in {op_name} expression"
+ )
+ })?;
+ let expr = match left_type {
+ DataType::Dictionary(_, inner) if *inner == DataType::Utf8 =>
Box::new(expr),
Review Comment:
Thanks for the review!
You're right it's pre-existing — I checked the neighboring behavior: the
LIKE kernels handle `Dictionary(_, Utf8)` needles in the array-array path, but
the regex kernels (`regex_match_dyn`) only handle dictionaries in the scalar
fast path. With this PR those paths now return a proper error instead of
panicking, but dictionary support itself is indeed a separate concern.
Filed #23709 to track it.
--
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]
