[OffgridwithJD]

Part of #1339: the test_partition_lifecycle findings assigned to me. Each fix is in both twins.

Findings

finding	what changed	proof
:497 [weak], drop plan	The RANGE-on-one-column check had only an unpartitioned table to refuse, and NOT FOUND refuses that alone. A new arm adds a LIST parent and a two-column RANGE parent, each led by a timestamptz, so they pass the key check and only strat/natts stop them. Each refusal now asserts its message, not only 55000.	The check reduced to IF NOT FOUND: main 59/59 and pytest passed; here "got [55000 …dnl…|ok: 0|ok: 0]", both twins red
:92 [mislabelled]	premise: the parent now has the partitions it reported checks the function's own report, so it is an arm (#1236)	A create_ahead that leaves its last partition unattached: red in both twins, as a premise on main and as an arm here
:203 [inaccurate]	The pytest name was 31 two-byte characters, 62 bytes, under a name saying "63-character". It is now "é"*31 + "x", 63 bytes, as the shell's 63-ASCII-byte name is, and both arms say "63-byte".	An accuracy fix. I found no mutation that separates 62 bytes from 63. As a control, the name bound off by one byte reddens the arm in both twins on main and here.
:77 [weak] (missing arms)	Nothing new. Since #1350, every branch of partition_create_ahead has an arm.	width/ahead, RANGE-on-one-column and key type (#1350); month and year (#1350); DEFAULT, MAXVALUE and the 1000 cap (already on main)

:156 was fixed on main before this batch: the boundary rows are computed from the seed, not read from the function's bounds.

Evidence

• Clean: partition_lifecycle 60/60 and test_partition_lifecycle.py passed on each of PG 15–19.
• Mutants: PG17, against main 25118c0. Also run: the drop helper's key check removed, and its whole RANGE check removed. Main's arm already catches both, and so does this branch.
• Ledger:
  • one new row, dated, so rows go 2343 → 2344;
  • the :92 arm dated, so the census goes 1798 → 1797;
  • two renames, each keeping its row's history;
  • the eight neighbours the unattached partition reddens gain that mutation alongside their existing dates.
• Gate: rc=0 against main.
• Database-free set: 429 passed.

🤖 Generated with Claude Code

[jdatcmd]

Approving the content at b8ea210. On PG17 I reproduced the :497 claim with partition_drop_plan's check reduced to IF NOT FOUND:

• main: partition_lifecycle passes 59/59.
• this head: the new arm fails ("a drop plan for a parent not RANGE-partitioned on one column is refused, LIST and two-column RANGE included"): the LIST and two-column parents get through.

The :203 rename is honestly called an accuracy fix, with its off-by-one control.

Needs a rebase before merge. You based this on 25118c0, and #1355 has merged since (main 1933577, 2343 / 1796). With your delta I expect 2344 / 1795.

[OffgridwithJD]

@jdatcmd, rebased onto ff09c2c (#1359 merged). The new head is a3119fb, replacing b8ea210. Ledger: 2354 / 1797 (2353 + 1; never 1798 − 1).

• Conflict: only check_ledger_budget.txt. The tsv equals main plus my delta, with no duplicate keys, and the changed test lines match b8ea210 exactly.
• Evidence still applies: since the evidence base (25118c0), main has changed no product file and neither partition_lifecycle file, so partition_lifecycle 60/60 on 15–19 and the five mutant results stand.
• Checks: gate rc=0 with the census agreeing; database-free set 429 passed.

I'll ping on green CI.

[OffgridwithJD]

@jdatcmd, CI is green on a3119fb (15/15). Ready for your merge; #1358 is next.

[jdatcmd]

Re-approving a3119fb.

• Ledger: a recount gives 2354 / 1797, which agrees with the budget. No duplicate keys, no dated premise: row.
• Patch: the partition_lifecycle changes are identical to b8ea210, the head I reviewed and reproduced (59 lines).
• Database-free set: 429 passed.

Merging.