fix(query): avoid planner panic for invalid LIKE ESCAPE literals

[sundy-li]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Fixes #19562

• validate LIKE/NOT LIKE/LIKE ANY ... ESCAPE literals during planner type checking so invalid escape strings return a semantic error instead of panicking
• add planner regression coverage for empty and multi-character ESCAPE literals

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1c3a372e77

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Validate ESCAPE in LIKE subquery comparisons too

This new check only runs through resolve_like/resolve_like_escape. Expr::LikeSubquery still goes through resolve_scalar_subquery (type_check.rs:1315-1327,1601-1613), which converts BinaryOperator::Like(escape) straight into SubqueryComparisonOp::Like without validating the literal, and the runtime LIKE path in comparison.rs:1263-1268 just uses the first character (or ignores an empty string). So queries such as SELECT 'a' LIKE ANY (SELECT 'a') ESCAPE 'ab' or ... ESCAPE '' are still accepted instead of raising the new semantic error, leaving this fix incomplete for subquery forms.

Useful? React with 👍 / 👎.

[sundy-li]

Validated LIKE ESCAPE in resolve_scalar_subquery before building SubqueryComparisonOp::Like, and added planner coverage for invalid LIKE ANY (SELECT ...) ESCAPE literals (`` and ab).

[sundy-li]

The new validate_like_escape helper only runs through resolve_like and resolve_like_escape. LIKE ... (subquery) ESCAPE ... still goes through resolve_scalar_subquery -> SubqueryComparisonOp::Like without validating the escape literal, so queries like SELECT a LIKE ANY (SELECT a) ESCAPE or ... ESCAPE ab are still accepted instead of returning the new semantic error. Please validate the escape before constructing the subquery comparison and add a regression for a subquery form.

[github-actions]

🤖 CI Job Analysis

Workflow: 23499540917

📊 Summary

• Total Jobs: 86
• Failed Jobs: 1
• Retryable: 0
• Code Issues: 1

❌ NO RETRY NEEDED

All failures appear to be code/test issues requiring manual fixes.

🔍 Job Details

• ❌ linux / test_logs: Not retryable (Code/Test)

---

🤖 About

Automated analysis using job annotations to distinguish infrastructure issues (auto-retried) from code/test issues (manual fixes needed).