alan910127 commented on code in PR #15110:
URL: https://github.com/apache/datafusion/pull/15110#discussion_r1988192389
##########
datafusion/optimizer/src/simplify_expressions/unwrap_cast.rs:
##########
@@ -177,6 +192,45 @@ pub(super) fn
is_cast_expr_and_support_unwrap_cast_in_comparison_for_inlist<
true
}
+fn cast_literal_to_type_with_op(
+ lit_value: &ScalarValue,
+ target_type: &DataType,
+ op: Operator,
+) -> Option<ScalarValue> {
+ macro_rules! cast_or_else_return_none {
Review Comment:
> instead of doing another round of PR reviews I figured I would just push
the commits directly to save time.
Thank you! I’m just curious—is storing a parquet file in slt tests common?
The tests I’ve worked with so far use tables created in the same test file.
> Strangely they don't seem to care about errors:
Interesting! This makes me wonder if they treat this behavior as an
"optimization" or if it's simply an expected behavior that both sides of a
comparison operator should be of the same type.
> I played around a little locally and this is what I came up with. What do
you think?
Oh, this looks much better! However, I’d prefer leaving the outer match as
is, maybe there’s potential for another optimization in the future?
--
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
