[OffgridwithJD]

@jdatcmd Item 74's next twin-less suite: native_saop_pushdown.sh gets test_native_saop_pushdown.py, and the suite is seeded in the ledger.

The twin

All 53 checks by the shell's name, in eight tests over one module fixture (40000 rows, 20 groups, the overlap column). test_compare_to_bash accepts it in COMPLETE, and its literal tables join the loop-reader guard's list.

Red first, name for name. I ran a scratch runner (not committed) that wraps expect, records every red and carries on. Under each of the twelve dating mutations, the twin reddened exactly the shell's set of checks:

mutation	reds, shell = twin
#704's set key reverted (no key for any SAOP)	18
every list takes the hull	8
bound 128 → 127 / → 129	1 / 1
a NULL element bails out	3
the single distinct value emitted as a [v,v] range	1
set key never probes the bloom filter	19
zone map tests only the first element	7
freeze only a bare Param (the mixed IN (lit, $1) list)	1
walker calls PARAM_EXEC stable (frozen at Begin → backend crash)	2
reader drops a cross-type key	1
reject expression cut to SK_ISNULL	6

The crash mutation found the one gap. In the first draft the twin errored on the dead connection and named neither the correlated arm nor "backend alive". Both now read their value through a helper that turns a lost connection into a named red, in a last test of their own, ordered as in the shell.

Five-major runs at head: 53/53 for the shell and 53/53 for the twin, on each of 15–19.

Two stale comments, measured

• The '{25,25}' arm. The shell said it is the removal proof for the single-distinct-value equality key ("as two range keys it removes 0"). That stopped being true when the set form landed. With the refinement removed, the list takes the set path, whose bloom loop probes 25 as well and still removes all 20. The arm reddens only when the value is emitted as a range. The comment now says so.
• columnar_vector.c, at the exactness gate. It said native_saop_pushdown.sh's vector-agg arms go red if this gate regresses. For a SAOP it's one of three gates (allConvertible, exactness, and the keys' sk_flags != 0). Each one removed alone, and exactness plus allConvertible removed together, leave every arm green. Only all three removed redden "Batch Fold: no" and the exact count. Comment only, no behaviour change.

Ledger

Census 4101 / 2941 never / 1160 dated, with suites_not_covered 202 → 201. 35 of the 53 checks are dated. pgc_ledger.py gate --against the base gives rc 0, and orphan-scan finds 0. 18 arrive never:

• four premises;
• defence in depth: NOT IN (dropping !useOr alone stays green, because <> has no equality strategy) and the three batch-fold arms (above). No single-gate mutation reddens any of them, so they stay never. I added no fixture I couldn't make red;
• the parser-collapsed IN (25), which never reaches the set key;
• seven exact counts that no set-key mutation moves;
• SK_ISNULL, which can't leave the reject expression without reddening its premise, and the SK_SEARCHARRAY source arm.

The merge also re-sorted the five rewrite_storage_oid rows that #1475 renamed in place. That's the churn I mentioned on #1480. It sits in this PR's tsv diff, and the rows themselves are unchanged.

Collection gives cluster_tests 702 -> 710, and TESTS.md gets §164. The no-cluster guard set passes, 438/438.

🤖 Generated with Claude Code

[jdatcmd]

Approve, at 63ac69b. My own mutant, different from your twelve: in columnar_reader.c's skip-vector row test (the searchArray loop the refine pass calls), skip the last array element (i + 1 < arrayValueCount). PG17:

twin	reds
shell	4: scattered per-element pruning keeps the exact answer (2 want 3), the multi-value integer NULL set stays exact, the by-reference text NULL set stays exact, a range-spanning IN-list prunes between its elements (18/1 want 18/2)
pytest	3: the same, without the by-reference text NULL set

The pytest twin's missing red is masking, not a missing arm. Both NULL-set arms sit in test_nulls_types_and_collations_prune_exactly, and expect raises on the first red (41 of 53 checks ran). Your scratch runner that carries on after a red is why you saw exact parity; the real harness stops at the first. This is the same note as on #1480, and I don't think it blocks either PR.

Two smaller notes:

• columnar_vector.c: the change is comment-only, as you say. It's 5 lines in for 3 out, though, so every later ereport in that file now reports a __LINE__ two higher. CI's full suites will show whether anything reads it, and I merge only on full green.
• The census: #1479 also adds one row, so whichever merges second re-anchors (4101 + 1).

[jdatcmd]

@OffgridwithJD, merging #1482 now: approved at 63ac69b, 15/15 green, CLEAN.