From e2273930980bd405d5e65b00400f45aeab060591 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 8 Sep 2026 18:09:24 -0600 Subject: [PATCH] docs: open [Unreleased] and record the rename fix (#888) #888 merged without a changelog entry. Every recent PR touching src/ carries one (#883, #880, #873, #872), and this one had a reason to be awkward rather than a reason to be absent: #886 closed the changelog for 1.0-alpha3, so there was no [Unreleased] section to add to. This opens one. The entry says what the defect actually was, which is not obvious from the title. The materialized projection stores attnums and followed a rename already; the DECLARATION stores names, because a restore assigns new attnums. So the live projection kept working right up to the backup and the breakage only appeared during rebuild_projections() after a restore -- invisible until the moment it mattered. It also records the number that makes the descendant arm worth having: mutating the walk to use the named relation instead of each descendant takes test/projection_rename_restore.sh from 8 passed to 6 passed and 2 failed. That was measured on this tree, both arms built in the same directory so the .so fingerprint reflects the source and not the build path. docs_style.sh: 9 checks, PASSED. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Unuuvh3fRR67SceiGpfeeK --- CHANGELOG.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 896d687c..c499ef75 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -14,6 +14,25 @@ installed, `1.0-alpha`, and `1.0-alpha2`), so a single notes in this file describe `default_version` as pinned at an earlier version, each true until the next version shipped. +## [Unreleased] + +### Fixed + +- `ALTER TABLE ... RENAME COLUMN` now carries the new name into + `pgcolumnar.projection_declaration`, for the named relation and for every + inheritance descendant (#888). + + The materialized projection stores attnums, so it already followed a rename + without any catalog change. The declaration deliberately stores NAMES, because + a restore assigns new attnums -- so leaving the old name behind broke + `pgcolumnar.rebuild_projections()` after a dump and restore, even though the + live projection had kept working right up to the backup. The failure was + therefore invisible until the moment it mattered. + + The descendant half is held by an arm that was proved able to fail: changing + the walk to use the named relation instead of each descendant takes + `test/projection_rename_restore.sh` from 8 passed to 6 passed and 2 failed. + ## [1.0-alpha3] - 2026-09-02 ### Added