fmcmac opened a new pull request, #26467:
URL: https://github.com/apache/datafusion/pull/26467
## Which issue does this PR close?
No existing issue. This PR states the problem and a reproduction below.
## Rationale for this change
sqlparser parses `expr [NOT] RLIKE pattern` and `expr [NOT] REGEXP pattern`
for every dialect, but DataFusion refuses both:
```sql
SELECT 'abc' RLIKE '^a';
-- Error: This feature is not implemented: Unsupported ast node in sqltorel:
RLike { negated: false, .. }
```
Expected: `true`. DataFusion already has the semantics as `regexp_like(expr,
pattern)`. Spark, Hive and MySQL users write these operators directly.
## What changes are included in this PR?
- `SqlToRel` plans `expr [NOT] RLIKE|REGEXP pattern` as `[NOT]
regexp_like(expr, pattern)`.
- `regexp_like` resolves through `ContextProvider::get_function_meta`, the
same lookup as an explicit call. A session that overrides `regexp_like` gets
its override for all 3 spellings. A session without it gets a planning error
naming `regexp_like`.
- Explicit calls and the operators share a new `plan_scalar_udf` helper.
Registered `ExprPlanner::plan_scalar` hooks therefore see `RLIKE`, `REGEXP` and
their negations, just as they see `regexp_like(...)`. The helper keeps a
planner's result distinct from the default call, so a planner's rewrite is
returned as is and only the default call gets the alias for a function called
by another name.
- It plans as the function, not `Operator::RegexMatch`. The unparser renders
`RegexMatch` as `~` for every dialect, while a function call can be renamed per
dialect. The built-in's `simplify` still rewrites it to `~` for execution.
- Docs: `RLIKE` and `NOT RLIKE` in the operators guide.
## What is the testing strategy for this PR?
- `regexp/regexp_like.slt`: `RLIKE`, `REGEXP`, `NOT RLIKE` and `NOT REGEXP`
over the shared test data, a NULL subject, a NULL pattern, a column pattern,
and row-for-row agreement with `regexp_like(...)`.
- `sql_integration.rs`:
- `select_rlike_plans_as_regexp_like`: registry resolution and plan shape.
- `select_rlike_without_regexp_like`: the planning error.
- `select_rlike_with_expr_planner`: an `ExprPlanner` that rewrites
`regexp_like` to `~` applies to the explicit call, `RLIKE`, `REGEXP`, `NOT
RLIKE` and `NOT REGEXP`.
- `select_expr_planner_rewrite_to_other_function`: an `ExprPlanner` that
rewrites `regexp_like` to another scalar function keeps that function's output
name, for the explicit call and for `RLIKE`, with no alias back to
`regexp_like(...)`.
- All fail on `main`.
## Are there any user-facing changes?
Yes: `RLIKE` and `REGEXP` now plan instead of erroring. Documented in the
operators guide. `ExprPlanner::plan_scalar` now also sees these operators. No
public API change.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
