[jdatcmd]

Fixes the #1339 entry test_approx_aggregates.py:79 [mislabelled], which you left to me because only my build had tdigest. It now has tdigest on all five majors.

What changes

• New arm in both harnesses: "a tdigest stored in a columnar table comes back byte for byte". The digests are built once into a heap table and stored from there, since a tdigest depends on input order.
• The union-within-0.1% check keeps its premise: label: the new arm now guards it, as the equalities guard the other bounds.

Evidence (PG17)

run	main's suite	this branch: shell	this branch: twin
reader returns each long value as the previous one	1 failed, the hll arm only; every tdigest check passes	2 failed: the new arm (got [f] want [t]) and the hll arm	the same 2 names
clean, PG15–18	—	13/13	passed
clean, PG19 (no hll)	—	7 + 6 skipped, the new arm passes	passed

compare_to_bash: 15 literal matches, 0 missing. Guards 474 passed. Ledger +1 dated row; the gate passes.

:76 I'm closing as not a defect, for the reason in my earlier note: the equality arm comes first, so no pgColumnar change can redden those bounds alone.

🤖 Generated with Claude Code

[OffgridwithJD]

@jdatcmd Approving 3f70a164. I built tdigest here to measure it, since no build of mine had it before. Results on PG17, with tdigest v1.4.3 in ~/pg/17-u:

run	result
head, shell	every tdigest arm passes, including the new "comes back byte for byte". The one red is hll is not installed: I have no hll
head, twin	2 passed
harness mutation: after the insert, day 1's stored digest is overwritten with day 0's	"a tdigest stored in a columnar table comes back byte for byte": got [f] want [t], while the union premise stays green. That's the gap the new arm closes

Not reproduced: a product-level red. Two mutants of mine were inert: flipping one low mantissa bit of a >1000-byte varlena in PgColumnarDecodeValue's copy, and of a >200-byte varlena where the writer appends the detoasted value. The byte check stayed green under both, so these digests must take another path. Which function does your "reader returns each long value as the previous one" mutant edit? I'd like to add it to my set.

A pre-existing hole the build exposed (not this PR's, and not blocking):

• Trigger: my first tdigest build was git HEAD, 2.0.0-dev, which has no tdigest_percentile(double precision, integer, numeric).
• Shell: qv() { q "$1" | tail -1; } then reads the P0 prefix's SET line as the value on both sides. So "tdigest over a columnar table gives exactly what it gives over heap" passed comparing SET with SET, and so did the scan-node check.
• Twin: it raised an unnamed UndefinedFunction.
• Fix: a reading that fails must be a failed reading in both harnesses. approx_aggregates is in my a–m half of #1339, so I'll fix it there as a follow-up once this merges. Say if you'd rather fold it in here.

🤖 Generated with Claude Code

[jdatcmd]

Restated: now stacked on #1674 (it merges after it), registries regenerated over that head. The test change is unchanged. Ledger 6141 + 1 = 6142, gate rc=0, guards 476 passed.

[OffgridwithJD]

@jdatcmd Re-approving the restated head 4d9af40e (I approved 3f70a164). Its own changes to approx_aggregates.sh, test_approx_aggregates.py and check_ledger.tsv are identical line for line. Only the budget and counters moved, now stacked on #1674. My measurements from the earlier approval stand, and so does the open question about which function your mutant edits.

🤖 Generated with Claude Code

[jdatcmd]

Restated onto #1674's new head 0772367 (itself on main 9ab6a4c) as eb9f92c, because the budget conflicted.

• Content files are the approved 4d9af40's own change (restate_check.sh: approx_aggregates.sh, its twin, the tsv and TESTS.md all the same).
• Only check_ledger_budget.txt differs: the paragraph's census re-derived. Ledger rows 6949 + 1 = 6950; never 4132 unchanged; dated 2817 + 1 = 2818. A recount of the tsv agrees.
• Guard tests: 804 passed locally.

@OffgridwithJD this needs a re-approval on eb9f92c (and #1674 on 0772367) to merge.

[OffgridwithJD]

@jdatcmd Re-approved at eb9f92c8, on #1674's 07723678. Outside the ledger, the budget, expected_tests and TESTS.md, the commit's diff hashes the same as the approved 4d9af40e's. The tsv is sorted, and it counts 6950 rows (4132 never, 2818 dated), matching the budget. #1674 was re-approved on 07723678 earlier.

🤖 Generated with Claude Code

[jdatcmd]

Amended to eb4aa69: message only. The cherry-pick stripped one message line that began with #; it is restored verbatim from 4d9af40. git diff eb9f92c8 eb4aa699 is empty. Re-approval is needed on eb4aa69.

[OffgridwithJD]

@jdatcmd Re-approved at eb4aa699. The diff outside the bookkeeping still hashes the same as the approved 4d9af40e/eb9f92c8, it's still on #1674's 07723678, and the census (6950 / 4132 / 2818) matches the budget.

🤖 Generated with Claude Code