rednaxelafx edited a comment on issue #27355: [SPARK-30625][SQL] Support `escape` as third parameter of the `like` function URL: https://github.com/apache/spark/pull/27355#issuecomment-584344438 Sorry for posting this review post-hoc, but I strongly believe this PR should be reverted and redesigned. There are both design and implementation issues with this PR: 1. Design: in order to get to feature parity between the `LIKE` syntax and the `like` built-in function, the latter should only accept `Char` argument for the `escapeChar` parameter, instead of the full-blown `Expression` -- the `LIKE` syntax only accepts a literal anyway. c.f. https://github.com/apache/spark/blob/a7451f44d234a946668deb99bed8fdbd4b8ebf8e/sql/catalyst/src/main/antlr4/org/apache/spark/sql/catalyst/parser/SqlBase.g4#L748 By not changing the `escapeChar` parameter to an `Expression`, we can avoid most of the complexity (and bugs) in this PR. 2. Implementation. The shim of `escapeChar = ...` to adapt the `Expression` argument back to a `Char` is very bad. See this example: ```scala Seq(("abc", "%bc", "/")).toDF("s", "p", "esc").selectExpr("like(s, p, esc)").explain(true) ``` and on a freshly built Apache Spark master, you'll get: ``` == Parsed Logical Plan == 'Project [unresolvedalias('like('s, 'p, 'esc), Some(org.apache.spark.sql.Column$$Lambda$2247/782587714@5cf3924c))] +- Project [_1#3 AS s#10, _2#4 AS p#11, _3#5 AS esc#12] +- LocalRelation [_1#3, _2#4, _3#5] == Analyzed Logical Plan == s LIKE p: boolean org.apache.spark.sql.AnalysisException: The 'escape' parameter must be a string literal.; == Optimized Logical Plan == org.apache.spark.sql.AnalysisException: The 'escape' parameter must be a string literal.; == Physical Plan == org.apache.spark.sql.AnalysisException: The 'escape' parameter must be a string literal.; ``` It doesn't look like supporting full-blown `Expression` for `escapeChar` is worth the cost here. EDIT: to make my comment clear: I do think it's reasonable to allow the builtin `like()` function have feature parity with what we support in the syntax, i.e. accepting a literal argument for `escapeChar`. So the underlying intent of this PR sounds good to me. It's just the details that don't look quite right. In order to support a 3-arg version of `like()` builtin function, we don't really have to change the signature of the primary constructor of `Like`. Instead, adding a constructor overload that takes the 3rd argument as an `Expression` and asserting that it only supports `Literal` or `foldable` would do. That way we can have feature parity without most of the changes in this PR.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
