scsmithr commented on PR #15110: URL: https://github.com/apache/datafusion/pull/15110#issuecomment-2715007343
> > I'm not sure if it's only possible to handle it when the cast is created (type coercion?) > > That may well be the right thing to do 🤔 > > It is funny that @scsmithr filed a ticket this morning with a similar symptom: > > * [Incorrect cast of integer columns to utf8 when comparing with utf8 constant #15161](https://github.com/apache/datafusion/issues/15161) > > > 🤔 For context, I was running some implicit cast queries on a few different systems to compare outputs, and hit the aforementioned issue with datafusion. "Unexpected" might be a better word than "incorrect", but datafusion is the outlier here. My take on this: I don't believe manipulating casts after-the-fact is the right approach. Given the query `select * from t1 where column1 < '10';` where `column1 is an Int32, the literal `'10'` should be treated as unknown, and the preference should be to cast that. The generated predicate should then be `column1 < cast('10' as int)`, and whatever const folding happens will then take care of parsing `'10'` as an int during planning. Without a proper "unknown" type, I think it should be sufficient to rank implicitly casting to utf8 last compared to any other implicit cast. -- 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
