### What problem does this PR solve?

Issue Number: None

Related PR: apache#68758

Problem Summary: Bring the branch up to date with master 3c060af, which the
PR could no longer merge with. apache#65684 (unify const column read method) edits
function_search.cpp and variant_inverted_index_search.cpp at the paths this PR
moved to exprs/function/search/; the other upstream changes merge cleanly.

The change is ported to the moved files: SEARCH and its NESTED evaluator take
the bound nested TabletColumn instead of the column-id map, and the evaluator
reads the VARIANT root through that column. The SEARCH tests and the SNII search
benchmark this PR added pass nullptr for the column, as master's tests do, and
the variant reader test master changed includes the moved SEARCH headers.

### Release note

None

### Check List (For Author)

- Test: Unit Test. 1,772 ASAN tests in 119 suites ran, including SEARCH,
  NESTED search, VSearchExpr and the suites of test files changed on both sides:
  1,769 pass and 3 skip by their own conditions. The merged SEARCH sources
  compile with GCC, and the merged-tree format preflight passes.
- Behavior changed: No additional query engine behavior changes.
- Does this need documentation: No

…n test

### What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: Rebasing onto master picked up apache#65684, which deleted
`DefaultValueColumnIterator` and moved default-value parsing into
`Segment::get_default_value_field`, together with a new
`constant_column_iterator_test.cpp`. That file's
`NonEmptyComplexTextDefaultsAreRejected` asserted the pre-PR restriction that
a non-empty ARRAY/MAP/STRUCT literal default is rejected
(`NOT_IMPLEMENTED_ERROR`), which no longer holds once this branch's earlier
commits teach the complex SerDes to parse such literals. Replace it with
`NonEmptyComplexTextDefaultsAreParsed`, asserting that `[1]`, `{"k":7}`, and a
positional struct literal are parsed into the matching typed `Field` through
`Segment::get_default_value_field`.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - `./run-be-ut.sh --run --filter="ConstantColumnIteratorTest.*" -j 32` (34 tests, all pass)
- Behavior changed: No (test-only; the behavior change itself is in the earlier commits)
- Does this need documentation: No

… unified constant column reader

### What problem does this PR solve?

Issue Number: None

Related PR: apache#68125

Problem Summary: master now resolves a single-version segment's `__DORIS_VERSION_COL__`, `__DORIS_COMMIT_TSO_COL__` and `__DORIS_BINLOG_TSO__` inside `Segment` with a request-scoped `ConstantColumnReader` (apache#65684): predicate and expression zone maps, MIN/MAX statistics, Bloom filter, page zone map and inverted index pruning all see the logical value, the reader never enters the UID-keyed cache, and `SegmentIterator` no longer rewrites those columns after the read. That replaces the segment-side part of this change, so the rebase keeps only the paths `Segment` does not cover: point-query and row-ID direct reads of the row store, the online index build's read options and replacement metadata, ordered link compaction and the JSONB decode row count.

This commit adapts what is left to the unified reader. `get_read_time_hidden_column_value` loses the `read_row_binlog` parameter that only `SegmentIterator` used to need: direct reads answer VERSION/COMMIT_TSO of a single-version rowset without opening the segment and leave every other column, BINLOG_TSO included, to `Segment`, which synthesizes it from the same rowset version and commit TSO the row-ID fetcher and the point query now put into their `StorageReadOptions`. The point-query comment that declared read-time hidden columns unsupported on the full-row-store fast path is replaced by what `Reusable::init` does: it takes them out of the JSONB decode and the row cache.

The segment-level unit tests of this change are rebuilt on the master fixture. They still write the physical placeholder (0 or NULL) under a Bloom filter, page zone maps and an inverted index, and assert that a single-version read returns the rowset value for predicates, expression zone maps and MIN/MAX pushdown, that no physical index filters rows, and that the constant reader neither reuses nor pollutes the cached physical reader. Two expectations follow the unified reader: a forced or regular MIN/MAX over VERSION or BINLOG_TSO now runs on the statistics iterator with the read-time constant instead of falling back to `SegmentIterator`, and a BINLOG_TSO read with an unassigned commit TSO is rejected by `Segment` rather than answered with 0, which master already covers.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - `SegmentIteratorExprZonemapTest.*`, `PointQueryHiddenColumnTest.*`, `BlockSerializeTest.*`, `OrderedDataCompactionTest.*` and `IndexBuilderTest.ReplacementRowsetKeepsPublishTimeMetadata` with the adapted helper.
- Behavior changed: No
- Does this need documentation: No

…substitutes their zone maps

apache#65684 reads the hidden version/TSO columns of a single-version segment through a
ConstantColumnReader whose zone map is the substituted value, so expr zone-map
pruning no longer sees the on-disk placeholder. Remove is_read_time_substituted_col
and keep the regression, plus a miss case that pruning on the real value handles.

Co-Authored-By: Claude Code <[email protected]>

… unified constant column reader

### What problem does this PR solve?

Issue Number: None

Related PR: apache#68125

Problem Summary: master now resolves a single-version segment's `__DORIS_VERSION_COL__`, `__DORIS_COMMIT_TSO_COL__` and `__DORIS_BINLOG_TSO__` inside `Segment` with a request-scoped `ConstantColumnReader` (apache#65684): predicate and expression zone maps, MIN/MAX statistics, Bloom filter, page zone map and inverted index pruning all see the logical value, the reader never enters the UID-keyed cache, and `SegmentIterator` no longer rewrites those columns after the read. That replaces the segment-side part of this change, so the rebase keeps only the paths `Segment` does not cover: point-query and row-ID direct reads of the row store, the online index build's read options and replacement metadata, ordered link compaction and the JSONB decode row count.

This commit adapts what is left to the unified reader. `get_read_time_hidden_column_value` loses the `read_row_binlog` parameter that only `SegmentIterator` used to need: direct reads answer VERSION/COMMIT_TSO of a single-version rowset without opening the segment and leave every other column, BINLOG_TSO included, to `Segment`, which synthesizes it from the same rowset version and commit TSO the row-ID fetcher and the point query now put into their `StorageReadOptions`. The point-query comment that declared read-time hidden columns unsupported on the full-row-store fast path is replaced by what `Reusable::init` does: it takes them out of the JSONB decode and the row cache.

The segment-level unit tests of this change are rebuilt on the master fixture. They still write the physical placeholder (0 or NULL) under a Bloom filter, page zone maps and an inverted index, and assert that a single-version read returns the rowset value for predicates, expression zone maps and MIN/MAX pushdown, that no physical index filters rows, and that the constant reader neither reuses nor pollutes the cached physical reader. Two expectations follow the unified reader: a forced or regular MIN/MAX over VERSION or BINLOG_TSO now runs on the statistics iterator with the read-time constant instead of falling back to `SegmentIterator`, and a BINLOG_TSO read with an unassigned commit TSO is rejected by `Segment` rather than answered with 0, which master already covers.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - `SegmentIteratorExprZonemapTest.*`, `PointQueryHiddenColumnTest.*`, `BlockSerializeTest.*`, `OrderedDataCompactionTest.*` and `IndexBuilderTest.ReplacementRowsetKeepsPublishTimeMetadata` with the adapted helper.
- Behavior changed: No
- Does this need documentation: No

…n test

### What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: Rebasing onto master picked up apache#65684, which deleted
`DefaultValueColumnIterator` and moved default-value parsing into
`Segment::get_default_value_field`, together with a new
`constant_column_iterator_test.cpp`. That file's
`NonEmptyComplexTextDefaultsAreRejected` asserted the pre-PR restriction that
a non-empty ARRAY/MAP/STRUCT literal default is rejected
(`NOT_IMPLEMENTED_ERROR`), which no longer holds once this branch's earlier
commits teach the complex SerDes to parse such literals. Replace it with
`NonEmptyComplexTextDefaultsAreParsed`, asserting that `[1]`, `{"k":7}`, and a
positional struct literal are parsed into the matching typed `Field` through
`Segment::get_default_value_field`.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - `./run-be-ut.sh --run --filter="ConstantColumnIteratorTest.*" -j 32` (34 tests, all pass)
- Behavior changed: No (test-only; the behavior change itself is in the earlier commits)
- Does this need documentation: No

…sion zone map pruning (#67774)

Zone map pruning only fires when a predicate compares a column against a
constant. A predicate over two columns of the same table, `WHERE a != b`
or `WHERE a < b`, never participates, so every segment and every Parquet
row group is read even when the two columns' min/max ranges make the
predicate unsatisfiable.

Everything on the path except the leaf already supports this.
`ZoneMapEvalContext` is keyed per slot and the segment-level and Parquet
row-group-level callers already populate an entry for every slot a
compound expression references, which is why cross-column AND / OR
compounds prune today. What was missing is the comparison operator's
capability gate: it accepts one slot plus one literal and nothing else,
so a two-slot comparison is dropped before evaluation.

This PR adds the slot-vs-slot shape next to the existing slot-vs-literal
one and gives the six always-false tests a single implementation shared
by both. With the left operand's non-null values in `[lmin, lmax]` and
the right operand's in `[rmin, rmax]`, the comparison cannot be TRUE for
any row when:

| operator | condition |
| --- | --- |
| `=` | `lmin > rmax \|\| rmin > lmax` |
| `!=` | `lmin == lmax && rmin == rmax && lmin == rmin` |
| `<` | `lmin >= rmax` |
| `<=` | `lmin > rmax` |
| `>` | `rmin >= lmax` |
| `>=` | `rmin > lmax` |

Substituting the degenerate range `[literal, literal]` for the right
operand reduces each row to the slot-vs-literal test already in the
tree, so the single-column path keeps its exact current behaviour. The
existing tests passing unchanged is the mechanical check on that.

`kNoMatch` means "no row in this zone can make the conjunct TRUE", not
"every row is FALSE", so NULL does not weaken these rules: a WHERE
conjunct discards FALSE and NULL alike, and the bounds summarize exactly
the non-null values. A column with no non-null value at all makes the
comparison NULL on every row and returns `kNoMatch` unconditionally.

One trap for reviewers: `can_evaluate` must not be widened. It is shared
by dictionary filtering and by `can_evaluate_equality`, and both
dereference `extract_slot_and_literal` behind a `DORIS_CHECK`, so
accepting a slot-vs-slot expression there would abort. This PR adds a
separate `can_evaluate_slot_slot` and ORs it into
`can_evaluate_zonemap_filter` only; a unit test pins that down.

Three deliberate limitations: a cast around either operand is rejected,
because the bounds are raw stored values and the optimizer inserts a
cast whenever the two column types differ; on Parquet a floating column
pair does not prune at all, because Parquet bounds omit NaN without
reporting how many were skipped, which would flip the `!=` rule; and
VARIANT, JSONB, ARRAY/MAP/STRUCT and aggregate-state columns are not
admitted, because `Field` compares any two of their values as equal, and
a segment types a VARIANT path slot by its inferred leaf type, which the
expression's VARIANT type would not match.

The v1 Parquet reader is excluded from slot-vs-slot pruning entirely,
because that reader is being removed. `_process_expr_zonemap_filter`
restricts itself to single-slot conjuncts (the v1 page path already
required a single column), so column-vs-column pruning runs on native
segments and the v2 Parquet reader only. This also moots the v1-specific
slot-vs-slot review threads here (malformed fixed-width statistics,
VARBINARY mapping, and the adjusted-UTC timestamp rollback tracked by
the now-closed #68118). The v1 single-column path keeps the
decimal-domain and NaN fixes described next.

A limitation on the v1 single-column path came out of review.
`ParquetPredicate::parse_min_max_value` decodes v1 bounds in the file's
own logical type, while `_type_matches` compares only primitive types,
so a file DECIMAL at scale 3 and a table DECIMAL at scale 2 both passed
and their unscaled payloads were then compared as if they shared a
domain. The v1 reader now leaves the zone map out unless the file and
table types agree, which is the check `format_v2` already applies. That
costs pruning in three narrow places, all of them correctness-driven: a
DATETIMEV2 or TIMESTAMPTZ column whose declared scale differs from the
Parquet unit loses expression zone map pruning entirely, which is the
widest practical case and matches the policy already written down for
the slot-vs-literal path; a decimal pair differing only in precision is
domain-identical yet also skipped; and IS NULL / IS NOT NULL pruning
goes with it, because a zone map carrying only the null flags leaves
min/max at `TYPE_NULL` and any range predicate would then fail
`range_stats_usable_for_zonemap`'s type check.

This also fixes a bug it uncovered. The flag that carries "these bounds
came from Parquet, so a hidden NaN is possible" was only ever set in the
format_v2 reader; the v1 reader assigned the slot's data type and left
the flag at its default, so the NaN guard never fired on that path. Two
DOUBLE columns whose Parquet bounds both read `[1.0, 1.0]` were then
pruned by the `!=` rule even when one of them hid a NaN, dropping a row
that should have come back. The rule now lives in one setter on
`SlotZoneMap` that assigns the type and the flag together, and all three
Parquet call sites go through it.

The hidden version and TSO columns need no special handling here: since
#65684, a single-version segment reads them through a
`ConstantColumnReader` whose zone map holds the substituted value, so
pruning sees the same value the rows come back with.

…cuit

### What problem does this PR solve?

Issue Number: None

Related PR: apache#65684, apache#68097

Problem Summary:

A singleton rowset stores only a placeholder for `__DORIS_VERSION_COL__` and
`__DORIS_COMMIT_TSO_COL__`; the real value comes from the rowset metadata at read time. The
short-circuit point query reads the JSONB row store, which holds that placeholder, and the BE
fast path deliberately does not resolve these columns (see `point_query_executor.cpp`). So on a
MOW table with `store_row_column = true`:

```sql
CREATE TABLE b (id INT NOT NULL, v INT) UNIQUE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES ('replication_num'='1', 'enable_unique_key_merge_on_write'='true',
            'store_row_column'='true', 'changelog.enable'='true');
INSERT INTO b VALUES (1, 7), (2, 8);
SELECT __DORIS_VERSION_COL__, __DORIS_COMMIT_TSO_COL__, v FROM b WHERE id = 1;
-- before: 0, 0, 7          after: 2, <commit tso>, 7
```

The columns can be named explicitly without `show_hidden_columns`, and `SELECT *` returns them
once `show_hidden_columns` is on. The regular scan path resolves them from the rowset correctly.

`LogicalResultSinkToShortCircuitPointQuery` now keeps any query that reads a hidden column on
the regular scan: it checks the project's input slots for `sink(project(filter(scan)))` and the
sink's input slots for `sink(filter(scan))`. Queries reading only visible columns keep the
short circuit, including a plain `SELECT *` (hidden columns are not expanded by default) and
server-side prepared statements.

### Release note

Fix point queries on row-store MOW tables returning 0 for `__DORIS_VERSION_COL__` and
`__DORIS_COMMIT_TSO_COL__`. Point queries that read hidden columns no longer use the
short-circuit path.

### Check List (For Author)

- Test: Regression test / Unit Test / Manual test
    - FE UT `ShortCircuitPointQueryTest` (10 cases, 2 new) passes.
    - New regression test `test_short_circuit_rowset_hidden_columns` fails on the unfixed FE
      (explain still shows SHORT-CIRCUIT) and passes with the fix; all 20 suites under
      `point_query_p0` pass.
    - Manual, local coupled cluster: the point query returns version 2 and the real commit TSO
      (default short circuit, `enable_short_circuit_query_access_column_store=false`, and
      server-side prepared statements); prepared statements reading only visible columns, and
      a plain `SELECT *`, still take the short circuit.
- Behavior changed: Yes. Point queries that read a hidden column (explicitly, or through
  `SELECT *` with `show_hidden_columns = true`) run as a regular scan instead of the short
  circuit. With `show_hidden_columns = true` such a query now also returns a row deleted by
  the delete sign, as a regular scan already does.
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 <[email protected]>