Skip to content

cat_tools 0.2.3: fix backwards relkind mapping#36

Merged
jnasbyupgrade merged 1 commit into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix-relkind-mapping-0.2.3
Jul 17, 2026
Merged

cat_tools 0.2.3: fix backwards relkind mapping#36
jnasbyupgrade merged 1 commit into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix-relkind-mapping-0.2.3

Conversation

@jnasbyupgrade

@jnasbyupgrade jnasbyupgrade commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

The bug

relation__kind() (relkind -> type) and relation__relkind() (type -> relkind), as shipped through 0.2.2, map the pg_class.relkind codes c, f, and m backwards.

Per pg_class.h the correct mapping is:

  • c = composite type
  • f = foreign table
  • m = materialized view

The code instead had c -> materialized view, f -> composite type, m -> foreign table (and the inverse in relation__relkind()). The other relkinds (r, i, S, t, v) were already correct.

The fix

  • Correct the c/f/m arms in both mapping functions in sql/cat_tools.sql.in (enum order and all other arms untouched).
  • Add upgrade script sql/cat_tools--0.2.2--0.2.3.sql.in that CREATE OR REPLACEs both functions with the corrected bodies, so an installed 0.2.2 picks up the fix via ALTER EXTENSION cat_tools UPDATE.
  • Bump to 0.2.3 (cat_tools.control default_version, META), regenerate the tracked sql/cat_tools--0.2.3.sql.in.

Test change

test/sql/relation_type.sql previously built its kinds view by positionally zipping enum_range('relation_type') against enum_range('relation_relkind'). Because the enum declaration order itself encoded the buggy pairing, that test was tautological — it could never catch a backwards mapping. It is rewritten to use hard-coded canonical (relkind, kind) VALUES pairs (only the relkinds present in the master enums), so the existing assertions now genuinely verify the mapping. No relkind-drift machinery added (out of scope).

Upgrade path (verified locally, PG17 and PG12)

CREATE EXTENSION cat_tools VERSION '0.2.2';
ALTER EXTENSION cat_tools UPDATE;   -- lands at 0.2.3
SELECT cat_tools.relation__kind('c');   -- composite type
SELECT cat_tools.relation__kind('f');   -- foreign table
SELECT cat_tools.relation__kind('m');   -- materialized view
SELECT cat_tools.relation__relkind('composite type');    -- c
SELECT cat_tools.relation__relkind('foreign table');     -- f
SELECT cat_tools.relation__relkind('materialized view'); -- m

CI version assertions updated 0.2.2 -> 0.2.3; the existing extension-update-test now exercises 0.2.0/0.2.1 -> 0.2.2 -> 0.2.3, covering the new upgrade script.

This is a minimal bugfix release — no other behavior changes.

Known CI dependency: binary pg_upgrade legs will fail until rebased

The Binary pg_upgrade matrix legs that cross a catalog-column removal boundary (→12, →13, →18) currently fail on this PR, and this is an expected, pre-existing cross-cutting dependency — not a defect in the relkind change:

  • The #18 pg_upgrade-compatibility fix (omitting relhasoids/relhaspkey and attcacheoff from _cat_tools.pg_class_v / _cat_tools.pg_attribute_v) was applied (commit 31204e1) only to the generated cat_tools--0.2.2.sql.in / upgrade scripts, and was never applied to the base source sql/cat_tools.sql.in.
  • Because this branch is cut from current master, the newly generated cat_tools--0.2.3.sql.in inherits the still-buggy base source, so a fresh 0.2.3 install builds views referencing relhasoids (removed in PG12) and attcacheoff (removed in PG18). Binary pg_upgrade to those versions then fails during pg_restore.
  • The base-source fix is owned by a separate branch (fix-28-install-upgrade-scripts). Once that lands, 0.2.3 must be rebased onto it and the pg_upgrade legs will go green. This PR deliberately does not touch omit_column / pg_class_v / pg_attribute_v to avoid colliding with that work.

All non-pg_upgrade CI legs pass: per-version tests (PG 10–18), extension-update-test (PG10), and review checks.

🤖 Generated with Claude Code

@coderabbitai

coderabbitai Bot commented Jul 15, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 89a9e698-09f6-4142-9610-f85219bad8f8

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@jnasbyupgrade
jnasbyupgrade force-pushed the fix-relkind-mapping-0.2.3 branch 7 times, most recently from 46cb6ee to c834d16 Compare July 17, 2026 23:41
relation__kind() and relation__relkind() (shipped through 0.2.2) mapped
pg_class.relkind values 'c', 'f', and 'm' backwards. Per pg_class.h the
correct mapping is 'c' = composite type, 'f' = foreign table,
'm' = materialized view; the code had 'c' -> materialized view,
'f' -> composite type, 'm' -> foreign table (and the inverse).

Changes:
- Correct the c/f/m arms in both mapping functions in cat_tools.sql.in.
- Add update script sql/cat_tools--0.2.2--0.2.3.sql.in that CREATE OR
  REPLACEs both functions so an installed 0.2.2 gets the fix via
  ALTER EXTENSION cat_tools UPDATE.
- Bump to 0.2.3 (control default_version, META; control.mk regenerated).
- Rewrite the relation_type test: the old `kinds` view positionally zipped
  enum_range('relation_type') against enum_range('relation_relkind'), which
  merely re-encoded the enum declaration order and could never detect a
  backwards mapping. Replace with hard-coded canonical (relkind, kind) pairs.
- HISTORY.asc 0.2.3 entry.
- Do not track the generated current-version install script
  sql/cat_tools--0.2.3.sql.in (gitignored, regenerated from source at build
  time); document the tracking-by-default policy and its minor-version
  exception in CLAUDE.md's SQL file conventions.
- Add RELEASE.md documenting the pgxntool-based release process
  (make tag / make dist mechanics, verified against pgxntool/base.mk).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@jnasbyupgrade
jnasbyupgrade force-pushed the fix-relkind-mapping-0.2.3 branch from c834d16 to 9635d29 Compare July 17, 2026 23:51
@jnasbyupgrade
jnasbyupgrade merged commit d84f3df into Postgres-Extensions:master Jul 17, 2026
19 checks passed
jnasbyupgrade added a commit to jnasbyupgrade/cat_tools that referenced this pull request Jul 18, 2026
Sync the long-lived new_functions (0.3.0 dev) branch with canonical master,
which advanced through Postgres-Extensions#38, Postgres-Extensions#37, Postgres-Extensions#32 and the Postgres-Extensions#36 0.2.3 release.

Conflict resolutions:
- sql/cat_tools.sql.in: new_functions relocated relation__kind()/relation__relkind()
  near the type definitions with the CORRECTED c/f/m mapping (an independent fix
  matching Postgres-Extensions#36) plus partitioned table/index arms; dropped master's copy at the old
  location to avoid duplicate definitions. The 0.2.3 relkind fix is preserved.
- sql.mk: took master's canonical sql.mk (owns `include pgxntool/base.mk`) as the base
  and re-applied new_functions' relkind drift-source generation block on top.
- Makefile: kept new_functions' TEST_LOAD_SOURCE harness; dropped the standalone
  base.mk include (sql.mk now owns it) and master's old TEST_BUILD_DIR machinery
  (its load_new.sql/load_upgrade.sql sources were removed on new_functions).
- .github/workflows/ci.yml: kept new_functions' harness CI (existing/update/fresh
  modes, bridge-journey pg-upgrade leg, existing_mode.sh). Postgres-Extensions#37's build-sourced dynamic
  version assertion is preserved via existing_mode.sh current_version().
- CLAUDE.md: superset — master's pgxntool note and SQL-conventions rules (with the
  0.2.3 exception) plus new_functions' harness CI documentation.
- HISTORY.asc: kept both the 0.3.0 and released 0.2.3 entries.
- version files (control, control.mk, META*.json): kept new_functions at 0.3.0.
- test/sql/relation_type.sql + .out: kept new_functions' deletion (superseded by
  relation__.sql, which carries the same de-tautologized canonical pairs Postgres-Extensions#36 added).
- sql/cat_tools--0.3.0.sql.in regenerated from the resolved cat_tools.sql.in.

Build clean; 14/14 tests pass in fresh and update (0.2.2->0.3.0) modes; verify-results green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant