Workflow [PR], commit [a5553c3]

Summary: ✅

• Performance Comparison: Performance dashboard

AI Review

Summary

This PR adds * LIKE and * ILIKE column-name pattern selection, extends qualified matcher expansion for the old and new analyzers, and documents/tests the behavior. I did not find unresolved correctness issues in the current diff; the earlier clickhouse-gh nested-matcher threads are addressed in the current code and resolved.

Missing context / blind spots

• ⚠️ I could not run the new stateless tests locally because this checkout has no build directory or clickhouse binary; the latest CI report for a5553c3d48741965e6fb7db90010cb5560865f2f still had most build/stateless/docs jobs pending. Completed CI would close this validation gap.

Final Verdict

Status: ✅ Approve

Note: this PR also fixes a related old-analyzer inconsistency discovered while implementing * ILIKE.

a.* ILIKE '<pattern>' is represented internally as a qualified COLUMNS regexp matcher, similar to a.COLUMNS(...). The new analyzer already supported that form, but the old analyzer did not fully expand qualified COLUMNS matchers, in particular through the multiple-join rewrite path.

To make a.* ILIKE ... work with enable_analyzer = 0, this PR also adds old-analyzer support for qualified COLUMNS regexp matchers. This fixes the new syntax and also resolves the pre-existing inconsistency for a.COLUMNS(...).

For example, before this PR, a query like this worked with the new analyzer but failed with enable_analyzer = 0:

SELECT a.COLUMNS('(?i)id$')
FROM (SELECT number AS UserID FROM numbers(1)) AS a
LEFT JOIN (SELECT number AS id FROM numbers(1)) AS b ON b.id = a.UserID
LEFT JOIN (SELECT number AS id FROM numbers(1)) AS c ON c.id = a.UserID
SETTINGS enable_analyzer = 0;

Hi @alexey-milovidov, this PR is ready for review, could you please help? Thanks.

This looks strange to me. First I thought it will apply the function to every column. For example:

SELECT count() FROM table WHERE * LIKE '%abc%'

But it does a different thing. How would we resolve this ambiguity later?
Is the Snowflake behavior widespread or just a random quirk? We shouldn't embrace random quirks.

Is the Snowflake behavior widespread or just a random quirk?

I checked support in other SQL dialects:

I also briefly checked Pinot/Druid/DataFusion/Trino and didn't find such capability.

So this is not Snowflake-specific (DuckDB has it as well) but it is not widespread either.

@alexey-milovidov please advise if we should proceed, and feel free to reject this PR if we consider this syntax too niche or not worth extending the parser for.

I'm ok with that, but let's also add LIKE support.

Added case-sensitive LIKE support alongside ILIKE, as requested.

• * LIKE '<pattern>' and qualified table.* LIKE '<pattern>' now work, matching column names case-sensitively (ILIKE remains case-insensitive). The shared parser helper accepts both keywords; LIKE builds a plain likePatternToRegexp matcher while ILIKE prepends (?i).
• Extended the test (now 04312_asterisk_like_ilike, renumbered to avoid a collision after merging master) with case-sensitive LIKE cases that demonstrate the difference from ILIKE (e.g. * LIKE 'foo%' matches foo but not FooBar), plus a qualified old-analyzer case and a no-match EMPTY_LIST_OF_COLUMNS_QUERIED case.
• Updated the documentation section to cover both LIKE and ILIKE.
• Merged master (the branch was ~3 weeks behind).

Verified locally on a freshly built binary: the test matches its reference, both serverError cases throw EMPTY_LIST_OF_COLUMNS_QUERIED, and a regression sweep (plain *, scalar/column LIKE, transformers, multiplication) is unaffected.

The only prior CI failure was CH Inc sync, which should be re-evaluated on this new commit now that master is merged.

@groeneai, investigate the failure: Upgrade check (amd_release) — "Error message in clickhouse-server.log" and provide a fix in a separate PR if needed. If the fix is already in progress, link it here.

The flagged error messages are all StorageKafka2 (... 03923_kafka2_keeper_offsets_...): Exception during get topic partitions from Kafka: Local: Broker transport failure — background polling errors emitted while the test Kafka broker is being torn down. They are unrelated to this PR, which only changes the SQL parser and old-analyzer expansion for * LIKE / * ILIKE column selection (no Kafka code touched).

I have merged the latest master into the branch and re-pushed, so CI will re-run on the fresh commit.

@alexey-milovidov, the fix is already merged: #106516 (merged 2026-06-06, master commit cfe19934d1).

The current 4e3bf67c head of this PR already includes that master merge, so the upgrade-check pipeline will re-run with the fix in place.

What the fix does: adds a regex allowlist line to tests/docker_scripts/upgrade_runner.sh that excludes the specific StorageKafka2 ... Exception during get topic partitions from Kafka: Local: Broker transport failure log emitted by KafkaConsumer2's background poll loop while the Redpanda broker is being torn down during the upgrade restart. The filter requires both the StorageKafka2 engine context AND the Broker transport failure symptom together, so real Kafka2 regressions (auth, timeouts, other broker errors) still surface.

Recurrence on this PR's fresh build with the fix in place would be a new flake, not the same one. CIDB shows this signature affected 53 unrelated PRs in 30d before the fix landed.

session: cron:clickhouse-ci-task-worker:20260607-171600

LLVM Coverage Report

Changed lines: Changed C/C++ lines covered by tests: 156/175 (89.14%) | Lost baseline coverage (was covered on master, now uncovered in this PR): 3 line(s) · Uncovered code

Full report · Diff report