LIKE fails on nested value

[neilconway]

Describe the bug

datafusion_physical_expr_common::datum::apply_cmp does not handle LikeMatch, ILikeMatch, etc for nested data types.

To Reproduce

CREATE TABLE t0(v0 BIGINT, v1 STRING, v2 BOOLEAN);
INSERT INTO t0(v0, v2) VALUES (123, true);
SELECT true FROM t0 WHERE ((REGEXP_MATCH(t0.v1, t0.v1)) NOT LIKE (REGEXP_MATCH(t0.v1, t0.v1, 'jH')));

Yields

Internal error: Assertion failed: matches!(op, Operator::Eq | Operator::NotEq | Operator::Lt | Operator::Gt |
Operator::LtEq | Operator::GtEq | Operator::IsDistinctFrom |
Operator::IsNotDistinctFrom) &&
left_data_type.equals_datatype(&right_data_type): invalid operator or data type mismatch for nested data, op !~~ left List(Utf8View), right List(Utf8View).
This issue was likely caused by a bug in DataFusion's code. Please help us to resolve this by filing a bug report in our issue tracker: https://github.com/apache/datafusion/issues

Expected behavior

No response

Additional context

No response

[Tushar7012]

Hi @neilconway ,
I looked into the issue and the failure seems to come from how apply_cmp currently assumes scalar (flat) inputs when handling operators like LIKE, NOT LIKE, and RegexMatch. When nested expressions (such as structs, lists, or other nested types) reach this path, the operator logic still gets applied, which leads to datatype mismatches and, in some cases, internal assertions instead of a user-facing error.

My approach is to fail fast and explicitly for nested data types. These operators don’t have a well-defined semantic meaning for nested inputs, so instead of letting them flow through and break later, the plan is to add a clear validation step before operator execution. If a nested type is detected, we return a descriptive execution error (for example, stating that LIKE / NOT LIKE / RegexMatch are not supported for nested types).

This keeps the behavior predictable, avoids panics or assertions, and aligns with how other unsupported operator/type combinations are handled in DataFusion. I’ll also add regression tests to ensure:

the original failure is covered, and

the new behavior returns a clean, informative error instead of crashing.

This should resolve the issue without introducing any breaking API changes or large refactors.

[neilconway]

@Tushar7012 Makes sense to me!

[Tushar7012]

Just having a PR for this Issue.....