alamb commented on code in PR #10323:
URL: https://github.com/apache/datafusion/pull/10323#discussion_r1586745915
##########
datafusion/optimizer/src/unwrap_cast_in_comparison.rs:
##########
@@ -298,19 +306,47 @@ fn is_support_data_type(data_type: &DataType) -> bool {
)
}
+/// Returns true if [UnwrapCastExprRewriter] supports casting this value as a
string
+fn is_supported_string_type(data_type: &DataType) -> bool {
+ matches!(data_type, DataType::Utf8 | DataType::LargeUtf8)
+}
+
+/// Returns true if [UnwrapCastExprRewriter] supports casting this value as a
dictionary
+fn is_supported_dictionary_type(data_type: &DataType) -> bool {
+ matches!(data_type,
+ DataType::Dictionary(_, inner) if is_supported_type(inner))
+}
+
+/// Convert a literal value from one data type to another
fn try_cast_literal_to_type(
lit_value: &ScalarValue,
target_type: &DataType,
-) -> Result<Option<ScalarValue>> {
+) -> Option<ScalarValue> {
let lit_data_type = lit_value.data_type();
- // the rule just support the signed numeric data type now
- if !is_support_data_type(&lit_data_type) ||
!is_support_data_type(target_type) {
- return Ok(None);
+ if !is_supported_type(&lit_data_type) || !is_supported_type(target_type) {
+ return None;
}
if lit_value.is_null() {
// null value can be cast to any type of null value
- return Ok(Some(ScalarValue::try_from(target_type)?));
+ return ScalarValue::try_from(target_type).ok();
Review Comment:
I wonder if ignoring errors will make tracking down unsupported types harder
(I am imagining when we try and add REEArray or StringViewArray).
##########
datafusion/optimizer/src/unwrap_cast_in_comparison.rs:
##########
@@ -298,19 +306,47 @@ fn is_support_data_type(data_type: &DataType) -> bool {
)
}
+/// Returns true if [UnwrapCastExprRewriter] supports casting this value as a
string
+fn is_supported_string_type(data_type: &DataType) -> bool {
+ matches!(data_type, DataType::Utf8 | DataType::LargeUtf8)
+}
+
+/// Returns true if [UnwrapCastExprRewriter] supports casting this value as a
dictionary
+fn is_supported_dictionary_type(data_type: &DataType) -> bool {
+ matches!(data_type,
+ DataType::Dictionary(_, inner) if is_supported_type(inner))
+}
+
+/// Convert a literal value from one data type to another
fn try_cast_literal_to_type(
lit_value: &ScalarValue,
target_type: &DataType,
-) -> Result<Option<ScalarValue>> {
+) -> Option<ScalarValue> {
let lit_data_type = lit_value.data_type();
- // the rule just support the signed numeric data type now
- if !is_support_data_type(&lit_data_type) ||
!is_support_data_type(target_type) {
- return Ok(None);
+ if !is_supported_type(&lit_data_type) || !is_supported_type(target_type) {
+ return None;
}
if lit_value.is_null() {
// null value can be cast to any type of null value
- return Ok(Some(ScalarValue::try_from(target_type)?));
+ return ScalarValue::try_from(target_type).ok();
Review Comment:
I wonder if ignoring errors will make tracking down unsupported types harder
(I am imagining when we try and add REEArray or StringViewArray). 🤔
--
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
