From 759bc544a643d449a1ec941ccdd6b273ccbf3e72 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 8 Sep 2026 18:39:46 -0600 Subject: [PATCH 1/2] docs: record #891, and correct two claims in this file Three changes, all to CHANGELOG.md. 1. #891 gets an entry. It merged without one, the same gap #888 had, except the excuse is gone: #893 opened [Unreleased], so there was a section to add to. The entry says what the symptom actually was, because the PR title does not: the next INSERT failed with "type with OID 0 does not exist" and the table stayed in that state. The scope in my first draft was wrong and I checked it against the merged code rather than shipping the peer's summary of it. I had written "a column named in a projection's sort key". The guard loops over projection->columns -- every column the projection STORES -- and its own comment explains that this covers sort keys as a consequence, because add_projection() requires every sort-key column to appear in columns. So the refusal is broader than "sort key" and the entry now says so. SQLSTATE read from ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST at src/columnar_tableam.c:2582, not from the PR description. 2. The intro said 1.0-alpha3 was "in development and not yet tagged; the latest published pre-release is v1.0-alpha2". It is tagged, and the tag is correct. I found this while filing a release-integrity issue that was itself wrong -- git fetch does not update an existing local tag ref, so git rev-parse showed a position the tag had been deliberately moved off days earlier. The issue is closed; this sentence was the one true thing in it. 3. #888's entry said "every inheritance descendant". The arm proves a PARTITION OF child, and a reader with a partitioned table searches for that word. Both are covered by find_all_inheritors; now both are named. (OffgridwithJD, #893 review.) docs_style.sh: 9 checks, PASSED. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Unuuvh3fRR67SceiGpfeeK --- CHANGELOG.md | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c499ef75..c1371daf 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,8 +6,8 @@ pre-release; the version marker is `1.0-alpha3`, recorded in `VERSION`. New tabl are written in the native on-disk format, PGCN v1. For the forward-looking plan see [design/ROADMAP.md](design/ROADMAP.md); for full history see the git log. -The extension's `default_version` is `1.0-alpha3`, which is in development and not -yet tagged; the latest published pre-release is `v1.0-alpha2`. Upgrade scripts from +The extension's `default_version` is `1.0-alpha3`, which is tagged as +`v1.0-alpha3` and is the latest published pre-release. Upgrade scripts from every previously shipped version ship with it (`1.0-dev`, which the v1.0-alpha tag installed, `1.0-alpha`, and `1.0-alpha2`), so a single `ALTER EXTENSION pgcolumnar UPDATE` reaches `1.0-alpha3` from any of them. Older @@ -20,7 +20,7 @@ true until the next version shipped. - `ALTER TABLE ... RENAME COLUMN` now carries the new name into `pgcolumnar.projection_declaration`, for the named relation and for every - inheritance descendant (#888). + inheritance descendant, including a `PARTITION OF` child (#888). The materialized projection stores attnums, so it already followed a rename without any catalog change. The declaration deliberately stores NAMES, because @@ -33,6 +33,17 @@ true until the next version shipped. 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. +- `ALTER TABLE ... DROP COLUMN` is now refused when a projection depends on the + column, instead of leaving the table unreadable (#891). + + Dropping a column that any projection stores produced + `ERROR: type with OID 0 does not exist` on the next `INSERT`, and the table + stayed in that state. The refusal raises `2BP01` + (`dependent_objects_still_exist`) and names the projection, so the remedy is + to drop the projection first. One loop covers sort keys too, because + `add_projection()` requires every sort-key column to appear in the stored + columns. `DROP COLUMN IF EXISTS` of a column that is not there is unaffected. + ## [1.0-alpha3] - 2026-09-02 ### Added From 416f0a5f684f6a1dc730eda5091ec89caad79f87 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 8 Sep 2026 20:54:46 -0600 Subject: [PATCH 2/2] docs: the OID-0 symptom is sort-key-only, not any stored column (#891) My entry said dropping a column that any projection stores produced "ERROR: type with OID 0 does not exist" on the next INSERT. That symptom is sort-key-only, and I had generalised it from one case. Measured by OffgridwithJD on e42c80d, with the refusal disabled and a control, projection pp storing (a,b) with sort key (a): drop a -- the sort key INSERT -> ERROR: type with OID 0 does not exist drop b -- stored, not key INSERT -> succeeds, 105 rows drop c -- not projected INSERT -> succeeds (control) So the refusal's SCOPE was right in the entry and its JUSTIFICATION was not. Dropping a stored non-sort-key column is still harmful, just elsewhere and more quietly: read_projection raises "cache lookup failed for type 0", the declaration still names the dropped column, and rebuild_projections() returns 0 -- repairing nothing while reporting success. That last part is the worse half, because it tells an operator there was nothing to do, and the entry now says so. Wording is OffgridwithJD's, from the #895 review. I have not re-run the measurement myself and am not claiming to; it carries a control and the mechanism matches the code, which is why I took it rather than asking for a second run. docs_style.sh: 9 checks, PASSED. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Unuuvh3fRR67SceiGpfeeK --- CHANGELOG.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c1371daf..b467fe31 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -36,13 +36,19 @@ true until the next version shipped. - `ALTER TABLE ... DROP COLUMN` is now refused when a projection depends on the column, instead of leaving the table unreadable (#891). - Dropping a column that any projection stores produced - `ERROR: type with OID 0 does not exist` on the next `INSERT`, and the table - stayed in that state. The refusal raises `2BP01` - (`dependent_objects_still_exist`) and names the projection, so the remedy is - to drop the projection first. One loop covers sort keys too, because - `add_projection()` requires every sort-key column to appear in the stored - columns. `DROP COLUMN IF EXISTS` of a column that is not there is unaffected. + Dropping a column any projection stores left the table broken, in one of two + ways. Dropping the **sort-key** column produced + `ERROR: type with OID 0 does not exist` on the next `INSERT`. Dropping any + other stored column let writes continue while `pgcolumnar.read_projection` + raised `cache lookup failed for type 0` and `pgcolumnar.rebuild_projections()` + reported repairing nothing -- the quieter and worse half, because it tells an + operator there was nothing to do. + + The refusal raises `2BP01` (`dependent_objects_still_exist`) and names the + projection, so the remedy is to drop the projection first. One loop covers + sort keys too, because `add_projection()` requires every sort-key column to + appear in the stored columns. `DROP COLUMN IF EXISTS` of a column that is not + there is unaffected. ## [1.0-alpha3] - 2026-09-02