Workflow [PR], commit [f6525f5]

Summary: ✅

AI Review

Summary

This PR introduces a new JSON combined subcolumn syntax (json.@path) that merges literal and sub-object reads, adds dedicated combined-path serialization logic, updates parser support, and adds broad stateless coverage for Memory and MergeTree variants. I did not find additional high-confidence correctness, safety, or performance issues beyond already-posted inline discussion; overall implementation looks coherent and sufficiently tested for the introduced behavior.

Missing context

• ⚠️ No CI run logs or benchmark reports were provided in the review context, so I could not independently validate runtime/perf behavior beyond code and test diff inspection.

ClickHouse Rules

Final Verdict

• Status: ✅ Approve

This is useful when a path may hold either a scalar value or a nested object across different rows, and is more convenient than separately querying the literal sub-column (json.a) and the sub-object sub-column (json.^a).

Does, it also apply to root json as well?
Ie, json could return 42 or NULL or "null"?

Does, it also apply to root json as well?
Ie, json could return 42 or NULL or "null"?

No. Root JSON column can contain only objects.

In theory, you can already use Dynamic type for this purpose:

create table test (json_value Dynamic) engine=MergeTree order by tuple();
insert into test select 42::Int64;
insert into test select null;
insert into test select 'data';
insert into test select '{"a" : {"b" : 42}}'::JSON;

select json_value, json_value.Int64, json_value.String, json_value.JSON, json_value.JSON.a.b from test;

   ┌─json_value─────┬─json_value.Int64─┬─json_value.String─┬─json_value.JSON─┬─json_value.JSON.a.b─┐
1. │ data           │             ᴺᵁᴸᴸ │ data              │ ᴺᵁᴸᴸ            │ ᴺᵁᴸᴸ                │
2. │ 42             │               42 │ ᴺᵁᴸᴸ              │ ᴺᵁᴸᴸ            │ ᴺᵁᴸᴸ                │
3. │ ᴺᵁᴸᴸ           │             ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ              │ ᴺᵁᴸᴸ            │ ᴺᵁᴸᴸ                │
4. │ {"a":{"b":42}} │             ᴺᵁᴸᴸ │ ᴺᵁᴸᴸ              │ {"a":{"b":42}}  │ 42                  │
   └────────────────┴──────────────────┴───────────────────┴─────────────────┴─────────────────────┘

But for this to work with JSON input formats we need to add support for JSON type in schema inference (right now objects are inferred as named tuples).

Or you can always wrap your JSON value into an object and just use JSON type: {"data" : {"json_value" : <anything>}}

#99920
If you are already looking at this failure, pls let me know )

If you are already looking at this failure, pls let me know )

No, I didn't look at it yet. You can go ahead (or assign me to the issue, I can also take a look)

LLVM Coverage Report

PR changed lines: PR changed-lines coverage: 88.70% (259/292, 0 noise lines excluded)
Diff coverage report
Uncovered code

Hi @Avogar @bharatnc — while reviewing this PR I found the following:

• Coverage gap: MergeTree deserialization of combined subcolumn with mixed literal and sub-object values untested — Add test: MergeTree deserialization of combined subcolumn with mixed l #101280

Could you review the test PR and add the can be tested label if it looks good?
Happy to discuss — close anything that's wrong or already addressed.