alamb opened a new issue, #4765: URL: https://github.com/apache/arrow-datafusion/issues/4765
**Describe the bug** There are two ways to express pattern matching in datafusion Exprs. ```rust Expr::Like(Like) .. ``` https://github.com/apache/arrow-datafusion/blob/3abbffb5c83395e8e6e68e5529835e72e7769d0d/datafusion/expr/src/operator.rs#L55-L61 As well as ```rust BinaryExpr { left: .. op: Operator::Like, right: .. } ``` This causes issues such as the simplification in https://github.com/apache/arrow-datafusion/pull/4646 only affects the BinaryExpr form, not the Expr::Like form The `Expr::Like` form is more full featured (can have pattern substitution) **Expected behavior** I would like to have a single way to represent these operators. I believe it should be `Expr::Like`, `Expr::ILike`, `Expr::NotLike` and `Expr::NotILike` as they have more features. Thus, I would like to remove `Operator::Like`, `Operator::ILike`, `Operator::NotLike`, and `Operator::NotILike` and update all tests / code to use Expr::Like **Additional context** Noticed while reviewing https://github.com/apache/arrow-datafusion/pull/4646 from @crepererum I am marking this as "good first issue" as it is mostly a software engineering exercise and would be guided by the compiler -- it would be a good exercise to get familiar with DataFusion's codebase -- 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]
