fix: accept LargeUtf8 and Utf8View patterns in SIMILAR TO planning

[u70b3]

Which issue does this PR close?

• Closes SIMILAR TO: SQL planner rejects non-literal LargeUtf8 / Utf8View patterns #23732

Rationale for this change

Follow-up to #23704, which made the TypeCoercion analyzer coerce SIMILAR TO operands to a common string type. The SQL planner still rejects LargeUtf8 and Utf8View patterns before the analyzer ever runs:

SELECT s FROM test, patterns WHERE s SIMILAR TO arrow_cast(pat, 'Utf8View');
-- error: Invalid pattern in SIMILAR TO expression

Now that the analyzer coerces both operands, this planner restriction is unnecessary (and inconsistent with LIKE, whose planner path has no such check).

What changes are included in this PR?

• datafusion/sql/src/expr/mod.rs: the pattern-type check in sql_similarto_to_expr now accepts Utf8 / LargeUtf8 / Utf8View / Null instead of only Utf8 / Null.
• datafusion/sqllogictest/test_files/type_coercion.slt: regression tests with non-literal Utf8View and LargeUtf8 patterns (plus a NOT SIMILAR TO case), next to the existing SIMILAR TO panics ('failed to downcast array') when operand types differ (e.g. NULL pattern, Utf8View vs Utf8) #22886 regression tests.

The planner relaxation and tests were originally part of #22887; this PR lands the remaining piece of it.

Are these changes tested?

Yes — new sqllogictest cases in type_coercion.slt. The existing planner rejection of non-string patterns (SELECT 'a' SIMILAR TO 1) still errors as before.

Are there any user-facing changes?

Yes: SIMILAR TO queries with non-literal LargeUtf8 / Utf8View patterns that previously failed during SQL planning with Invalid pattern in SIMILAR TO expression now plan and execute successfully. No breaking API changes.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.69%. Comparing base (994fc81) to head (9e61c37).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23735      +/-   ##
==========================================
- Coverage   80.69%   80.69%   -0.01%     
==========================================
  Files        1095     1095              
  Lines      372626   372622       -4     
  Branches   372626   372622       -4     
==========================================
- Hits       300700   300690      -10     
- Misses      53978    53979       +1     
- Partials    17948    17953       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[adriangb]

Can we add tests for teh null case?

[u70b3]

Done in add3f8d — added a literal NULL pattern in the table context and a non-scalar Null-typed pattern column (CREATE TABLE pn AS SELECT NULL AS pat), both evaluate to NULL.

[kosiew]

@u70b3
Thanks for working on this.
This is moving in the right direction, but I think there is still one blocking issue before we can remove the planner side type gate for SIMILAR TO.

[kosiew]

Thanks for expanding this to LargeUtf8 and Utf8View. I think we can go a bit further here though.

The planner still rejects dictionary encoded string patterns, so we still have the same duplicated planner and analyzer type gate that this PR is trying to remove. regex_coercion already handles dictionary string operands via dictionary_coercion, and it also owns the broader string-like coercion behaviour, such as REE when constructible.

Unlike SIMILAR TO, LIKE does not have an equivalent planner side check. As a result, this still fails during planning:

SELECT t.s SIMILAR TO arrow_cast(p.pat, 'Dictionary(Int32, Utf8)')
FROM t CROSS JOIN p;

with Invalid pattern in SIMILAR TO expression.

Could we let the analyzer own SIMILAR TO operand coercion and validation entirely, or otherwise accept all of the string-like types that it already supports? It would also be great to add a regression test for a dictionary encoded pattern.

[kosiew]

Small suggestion. Could we move the issue URL into the section heading instead of only this subsection comment? The existing Utf8View and LargeUtf8 value cases and these new pattern cases are all exercising the same SIMILAR TO coercion invariant, so it seems nice to have the issue reference apply to the whole section.

[u70b3]

Thanks for the review! I've removed the planner-side type gate so the analyzer now owns SIMILAR TO coercion and validation, added dictionary-pattern coverage, and moved the issue reference to the section heading. Fixed in a209834.

[kosiew]

@u70b3
Thanks for the iteration.

Looks 👍 to me

[adriangb]

thanks folks!