Skip to content

cat_tools 0.2.3: fix backwards relkind mapping#36

Open
jnasbyupgrade wants to merge 1 commit into
Postgres-Extensions:masterfrom
jnasbyupgrade:fix-relkind-mapping-0.2.3
Open

cat_tools 0.2.3: fix backwards relkind mapping#36
jnasbyupgrade wants to merge 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

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 upgrade script sql/cat_tools--0.2.2--0.2.3.sql.in that CREATE OR
  REPLACEs both functions so installed 0.2.2 gets the fix via
  ALTER EXTENSION cat_tools UPDATE.
- Bump to 0.2.3 (control default_version, META).
- 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.
- Update CI version assertions from 0.2.2 to 0.2.3.
- HISTORY.asc 0.2.3 entry.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@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: 98d2c7ef-9e1e-4de2-8e3e-a8a21d635b9f

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.

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