Add new functions, enums#16
Merged
jnasbyupgrade merged 121 commits intoJul 22, 2026
Merged
Conversation
Biggest change is that starting with Postgres 12 OID columns in catalog tables were no longer hidden, which required adjusting a few views and tests. Also update pgxntool.
Also, refactor common code between it and function__arg_types()
- Eliminate duplicate NULL array creation logic by restructuring CASE statement - Use pronargs instead of parsing proargtypes text for array size - Move data type definitions and mapping functions to beginning of file - Improve code organization and readability
- Add enum types equivalent to relation_relkind for pg_proc fields: * routine_prokind and routine_type (function/procedure/aggregate/window) * routine_proargmode and routine_argument_mode (in/out/inout/variadic/table) * routine_provolatile and routine_volatility (immutable/stable/volatile) * routine_proparallel and routine_parallel_safety (safe/restricted/unsafe) - Remove explicit type grants, rely on default privileges - Clean up redundant comments in mapping functions - Add comprehensive test suite for new enum types and permissions
54793a3 Merge branch 'master' into upstream/stable ab7f6e2 Stamp 1.0.0 3a571ba Add pg_tle support and modernize test infrastructure (#11) b96ea6d Add support for Claude code; build and doc improvements (#9) e9c24de Fix pg_regress on versions > 12 (#5) git-subtree-dir: pgxntool git-subtree-split: 54793a39251290657767816d23b45d6297f3a671
Versioned files should now be kept in git. Also, fix missing .gitignore
3b8cb2a Stamp 1.1.0 550a901 Remove commit.md (maintained in pgxntool-test) d73ca93 Add unique test database names to prevent conflicts (Postgres-Extensions#13) 9b344be Add update-setup-files.sh for 3-way merging after pgxntool-sync (#12) REVERT: 54793a3 Merge branch 'master' into upstream/stable REVERT: bed3604 Fix pg_regress on versions > 12 (#5) (#6) git-subtree-dir: pgxntool git-subtree-split: 3b8cb2a96c2611bb44b1d69fd533fd0f23fa8995
639756c Stamp 1.1.1 6ba3176 Fix pg_tle exception handler and empty upgrade files (Postgres-Extensions#15) git-subtree-dir: pgxntool git-subtree-split: 639756c43a64717347b82b46acfec5be478a7bbf
PostgreSQL 15 (commit 07eee5a0) moved "char" from TYPCATEGORY_STRING to
TYPCATEGORY_INTERNAL, which removed the implicit I/O coercion path that
allowed "char"::some_enum to work. Replace the "char" overloads for
routine__type, routine__argument_mode, routine__volatility, and
routine__parallel_safety with explicit CREATE CAST ... WITH INOUT AS
IMPLICIT entries.
Also fix two bugs in trigger__parse exposed by PG17:
- current_setting('server_version')::real fails when the version string
includes a distro suffix; switch to server_version_num::int
- pg_get_triggerdef renders temp functions as "pg_temp.f" while ::regproc
gives "pg_temp_N.f", breaking the regexp split on the EXECUTE clause;
replace the name-based pattern with a generic EXECUTE (FUNCTION|PROCEDURE)
regex
Fix PG15+ permission denied on public schema in object_type tests by
granting CREATE ON SCHEMA public to the test role (PG15 revoked this
from PUBLIC by default).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add all new types, casts, and functions to the upgrade file that were
previously only in the versioned install file:
- New routine enum types: routine_prokind, routine_type, routine_proargmode,
routine_argument_mode, routine_provolatile, routine_volatility,
routine_proparallel, routine_parallel_safety, and composite routine_argument
- CREATE CAST ("char" AS ...) WITH INOUT AS IMPLICIT for the four prokind/
proargmode/provolatile/proparallel enums (PG15+ compatibility)
- Functions: routine__type, routine__argument_mode, routine__volatility,
routine__parallel_safety, and trigger__parse(oid) with PG17 fixes
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Resolve conflicts keeping new_functions branch changes: - CI: updated PG version matrix (18..10) and test command - pgxntool: version history, unique REGRESS_DBNAME - trigger__parse: generic EXECUTE regex pattern - Test expected output and setup for new functions
121f0b3 Stamp 2.0.0 ad3ca7e Remove .source support; add test/install, test/build, and verify-results (Postgres-Extensions#18) c010cf8 Fix bash 3.2 compatibility (Postgres-Extensions#23) abeb9d3 Remove .source file support from pg_regress integration (Postgres-Extensions#22) 08c1879 Stamp 1.1.2 6e0dad2 Fix double --dbname bug that defeated unique test database names git-subtree-dir: pgxntool git-subtree-split: 121f0b38fabd1d0ebd2c975254e59421553e2830
…dy install/roles
- Move test/ci/existing_mode.sh -> bin/test_existing so it is locally runnable,
not CI-only. Add bin/<subcommand> symlinks (plant-guard, update, prepare-old,
run-suite, update-scenario, update-check) and dispatch on $(basename "$0"),
dropping the subcommand argument. Update ci.yml + doc references.
- Refactor bin/test_existing: main() defined first (invoked at bottom), cd to the
repo root derived from the script's own path (runs from anywhere), and dedupe
ALTER EXTENSION UPDATE by prepending "TO " only when a target is set.
- ci.yml: document the pg-upgrade-test and extension-update-test suites.
- test/install/load.sql: fold the "update must be committed" rationale into the
header, name DO-block dollar-quotes ($DO$), dedupe the update-mode ALTER
EXTENSION via a format('TO %L') clause, and label the stacked \endif closers.
- test/roles.sql: friendlier role names ("cat_tools testing: USE" / ": NO USE")
that still require quoting; all use sites already quote.
- CLAUDE.md: add the non-indentable-block-closer comment rule.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ebuild pg_class_v The 0.2.0->0.2.2 and 0.2.1->0.2.2 update scripts defined __cat_tools.omit_column with `attname != ANY(omit)`. For a multi-element omit array that predicate is true whenever attname differs from ANY single element, so it strips NOTHING. The intended omits therefore silently did nothing: _cat_tools.pg_class_v kept relhasoids/relhaspkey (and pg_attribute_v kept attmissingval/attcacheoff). A database updated 0.2.0/0.2.1 -> 0.2.2 on PG10/PG11 thus carried a pg_class_v referencing relhasoids/relhaspkey, which do not exist in PG12+, so a subsequent binary pg_upgrade to PG12+ failed. Fix in both update scripts: - Change omit_column to `attname != ALL(omit)` so multi-element omits work. - CREATE OR REPLACE VIEW cannot drop columns, so once the omit actually removes mid-list columns the old in-place recreate errors with "cannot drop columns from view". Convert the _cat_tools.pg_class_v recreation to a full DROP + CREATE of its dependency chain in reverse order without CASCADE: cat_tools.column, _cat_tools.column, _cat_tools.pg_attribute_v, cat_tools.pg_class(regclass) (it RETURNS the cat_tools.pg_class_v rowtype), cat_tools.pg_class_v, then _cat_tools.pg_class_v; recreate forward with the corrected omit, restoring all REVOKE/GRANTs. Add the same force-rebuild to the 0.2.2->0.2.3 script so a database that already reached the broken published 0.2.2 (via those bridge updates) is REPAIRED when it updates to 0.2.3. On a database whose view is already correct this is a harmless no-op rebuild. Only the .sql.in sources are edited; the versioned .sql are regenerated by make (SED version markers applied per target PostgreSQL major). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…t subcommands bin/test_existing dispatched on $(basename "$0") via a set of symlinks (bin/plant-guard, bin/update, ...). The symlink set was incomplete and the hardlink/symlink approach no longer fits a generic utility. Replace it with explicit `bin/test_existing <subcommand> [args]` dispatch (a case on $1), move the inline prepare-old/update-scenario/update-check bodies into named functions, and git rm the dispatch symlinks. Introduce psql helpers to cut duplication: psql_value (the repeated `psql -tAc` output-capturing calls) and psql_do (ON_ERROR_STOP statements / heredocs). Update all callers in ci.yml from bin/<subcommand> back to bin/test_existing <subcommand>. Still cd's to the repo root and is locally runnable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…dge PG10 to 0.2.3 Per Jim's decision, do NOT modify the already-shipped *--0.2.2 update scripts. Revert sql/cat_tools--0.2.0--0.2.2.sql.in and sql/cat_tools--0.2.1--0.2.2.sql.in to their shipped/master content (buggy `!= ANY` no-op omit + CREATE OR REPLACE); they ship that way. The pg_upgrade view fix reaches a database via the update path to the current version instead. Route 0.3.0's lineage through 0.2.3: 0.2.0 → 0.2.2 → 0.2.3 → 0.3.0 - Rename sql/cat_tools--0.2.2--0.3.0.sql.in → sql/cat_tools--0.2.3--0.3.0.sql.in (the features/enum-additions script). Removing the direct 0.2.2→0.3.0 edge forces `ALTER EXTENSION cat_tools UPDATE` to pass through 0.2.3. - The pg_class_v DROP+CREATE rebuild (with the `!= ALL` omit) already lives in 0.2.2→0.2.3, so it now runs on every update-to-current path, making the views pg_upgrade-safe. Bridge pg-upgrade test (PG10 leg): bridge_to 0.2.2 → 0.2.3. Bridging to 0.2.2 no longer fixes the views (shipped 0.2.0→0.2.2 is buggy); bridging to 0.2.3 runs the rebuild before pg_upgrade. 0.2.3 is also the furthest a PG10 cluster can reach — 0.2.3→0.3.0 uses ALTER TYPE ... ADD VALUE, unrunnable in an update script before PG12; the post-upgrade step then updates 0.2.3→current on the new (PG18) cluster. CLAUDE.md rule 4 rewritten to the general "changes little AND ships no nontrivial update-path machinery" test; docs/comments updated for the 0.2.3→0.3.0 rename. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The 0.2.2->0.2.3 update unconditionally DROP+CREATEd the public catalog view chain (cat_tools.pg_class_v, cat_tools.column, cat_tools.pg_class(regclass) and the _cat_tools.* backing views). That was only necessary for databases that reached 0.2.2 via the buggy 0.2.0/0.2.1->0.2.2 update scripts (whose omit_column used the no-op `!= ANY`, leaving relhasoids/relhaspkey in _cat_tools.pg_class_v). A fresh 0.2.2 install already has correct views, so the unconditional rebuild was not harmless: it dropped any user objects depending on those public views (or aborted the update, no CASCADE). Guard the whole drop+recreate inside a plpgsql DO block that runs only when _cat_tools.pg_class_v still has a column named relhasoids -- the fingerprint of the buggy-path build. A broken-via-update DB can only exist on PG<=10 (the only major where relhasoids exists to be captured), so a 0.2.2 DB on PG12+ is necessarily a fresh, correct install and is left untouched. DROP VIEW/FUNCTION cannot sit in a plain IF, so they run as EXECUTEd dynamic SQL alongside the existing format()-based CREATEs. The relkind-mapping fix is unchanged. test/build/upgrade.sql now plants user views depending on the public views before the update, proving a fresh 0.2.2 install's dependents survive the update to current (the old unconditional rebuild would have aborted here). README.asc/HISTORY.asc scope the dependent-objects caveat: the DROP+CREATE (and "drop your dependents first") applies ONLY to databases updated from 0.2.0/0.2.1; a fresh 0.2.2 install updating to 0.2.3 is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The extension-update-test PG10 leg already exercises the pre-0.2.2 update scripts (0.2.0/0.2.1 -> 0.2.2). Add a third update-check that installs 0.2.0 on PG10 (relhasoids present in _cat_tools.pg_class_v via the buggy 0.2.0--0.2.2 omit_column no-op) and updates to 0.2.3, which routes through 0.2.2--0.2.3 and must fire the conditional rebuild that strips relhasoids. A psql assertion fails loudly if relhasoids is still present after reaching 0.2.3, explicitly verifying the rebuild on the real broken path. 0.2.3 is the furthest PG10 can reach (0.2.3--0.3.0 needs PG12+). Complements the stronger 10->18 pg_upgrade bridge leg and mirrors the relhasoids assertion going into the Postgres-Extensions#42 replication. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Match the concise 0.2.3 entry going into the Postgres-Extensions#42 replication for consistency (most HISTORY entries are at most a paragraph). The detailed scoping of the conditional view rebuild remains in the README caveat. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…stgres-Extensions#42) new_functions' HISTORY 0.2.3 entry references a README "Updating the extension" section that did not exist here; the README instead carried an ad-hoc [NOTE] in the Views section. Add the formal section VERBATIM from the Postgres-Extensions#42 reroll branch (byte-identical, same placement after "=== Supported Versions") so the HISTORY reference resolves and the two branches' READMEs match ahead of the Postgres-Extensions#16->master merge. Remove the now-redundant Views [NOTE]: its content (rebuild scope + drop-dependents-first caveat scoped to 0.2.0/0.2.1, fresh install unaffected) is fully covered by the new section, which additionally documents the pg_upgrade ordering. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cktick identifiers) Replace the plain-text 0.2.3 entry with Postgres-Extensions#42's exact version, which backticks identifiers (`pg_class.relkind`, `relation__kind()`, `relhasoids`, `pg_class_v`, ...) per HISTORY.asc house style. The 0.2.3 block is now byte-identical between new_functions and the Postgres-Extensions#42 reroll branch. 0.3.0 entry untouched. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# Conflicts: # .github/workflows/ci.yml # CLAUDE.md # HISTORY.asc # META.in.json # META.json # RELEASE.md # cat_tools.control # control.mk # sql/cat_tools.sql.in # test/build/upgrade.sql # test/expected/relation_type.out # test/sql/relation_type.sql
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ting bugs in the code under test Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 21, 2026
# Conflicts: # .github/workflows/ci.yml # Makefile # bin/test_existing # sql/cat_tools.sql.in # test/build/expected/build.out # test/deps.sql # test/expected/permissions.out # test/install/load.sql # test/sql/permissions.sql
…e+upgrade paths back to PG10 The pg-upgrade-test matrix stopped at new_pg>=12 because the current 0.3.0 extension cannot be reached on PG11: the 0.2.3->0.3.0 update runs ALTER TYPE ... ADD VALUE, which cannot execute in an extension update script (a pre-PG12 transaction). But the value of a PG10->11 leg is guarding the 0.2.x-update and pg_upgrade harness paths all the way back to PG10/11, not testing 0.3.0 behavior there. Add an old_pg=10 -> new_pg=11 leg (install 0.2.0, bridge to 0.2.3 on PG10, binary pg_upgrade to PG11) with a new matrix field update_to that caps the post-upgrade version. update_to is empty on every new_pg>=12 leg (unchanged: update to current 0.3.0 + full existing-mode suite) and set to 0.2.3 on the capped leg. The two post-upgrade step-pairs are gated on update_to: empty runs update + run-suite as before; set runs a new verify-capped subcommand that asserts the extension is still at the capped version and re-proves the dependency guard survived pg_upgrade, without updating to current or running the 0.3.0 suite. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… comments The comments named 0.3.0 where they meant "the current / in-dev version we update TO", which rots the moment 0.3.0 ships. Replace those with the generic "the current version" (the harness's bare ALTER EXTENSION UPDATE already means current). Version numbers that name a HISTORIC released version or a specific historic update step are kept -- in particular "the 0.2.3->0.3.0 update runs ALTER TYPE ... ADD VALUE, unrunnable in a pre-PG12 transaction" stays, as it durably explains the PG12 floor. No matrix field values change (bridge_to / update_to "0.2.3" are historic and remain). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Give a reader the big picture in one place before the per-job details: the three ways a cat_tools install is reached (fresh install, in-place ALTER EXTENSION UPDATE, binary pg_upgrade) and why each is a separate job, the supported update origins (0.2.0/0.2.1/0.2.2), and the two PostgreSQL-version floors -- the pre-0.2.2 scripts load only on PG10, and the current version needs PG12+ because the 0.2.3->0.3.0 update runs ALTER TYPE ... ADD VALUE (unrunnable in a pre-PG12 transaction). The per-job leading comments are unchanged and remain the detail. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This reverts commit 6ffa3a6.
…or climb Every pg-upgrade leg now climbs to a PostgreSQL that supports the current version and updates to it + runs the full suite; nothing stops at 0.2.3. Remove the capped new_pg=11 leg, the update_to matrix field, and the verify-capped subcommand (with its usage/dispatch/header doc) that let a leg stop at 0.2.3 on PG11. The existing single-jump legs (10->18 from 0.2.0 and 0.2.1, 11->12, 11->18, 12->13, 12->18) are unchanged in behavior. Add a new pg-upgrade-stepwise job that installs 0.2.0 on PG10, bridges to 0.2.3, plants the dependency guard, then binary-pg_upgrades 10->11->12->...->18 one major at a time (holding the extension at 0.2.3 across the climb, since PG11 cannot run the 0.2.3->0.3.0 update), and on the final major updates to the current version, runs the full suite in existing mode, and re-proves the guard survived. This exercises every individual major-to-major transition rather than a single big jump. It is added to all-checks-passed needs. Add a top-level test-strategy overview before the test job: the ways an install is reached (fresh, in-place update, single-jump pg_upgrade, stepwise climb), the supported origins with the shortest-path rationale for testing 0.2.1 separately, the two PostgreSQL floors, and the invariant that every upgrade leg reaches PG12+ and updates to current. Comments keep only historic version numbers / the 0.2.3->0.3.0 step and otherwise say "the current version". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…rong bits Reshape pg-upgrade-stepwise so the suite runs at every major from PG12 upward, not only on the final PG18. The extension is still held at 0.2.3 for the 10->11 and 11->12 steps (PG11 cannot run the 0.2.3->0.3.0 update); on reaching PG12 it is updated to the current version once, and from PG12 on run-suite executes in existing mode after each major's pg_upgrade (12..18), re-proving the guard survived that step. A comment states the limitation: we cannot easily run the suite against 0.2.3 at the pre-PG12 steps because the suite matches the current version's objects and we do not maintain an old-version expected-output set, so those steps only verify 0.2.3 SURVIVES each pg_upgrade. Also drop the standalone `make test` call in the test job: base.mk declares `verify-results: test`, so `make verify-results` already runs the suite as a prerequisite and is the real gate (a bare `make test` never exits non-zero on regressions, installcheck is .IGNORE). And remove an incorrect sentence from the strategy overview claiming extension-update-test proves the update scripts converge to the same objects as a fresh install -- there is no object-comparison step in CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
|
@CodeRabbit please review |
|
✅ Action performedFull review finished. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pg_procfields:routine_type,routine_argument_mode,routine_volatility,routine_parallel_safetyrelation__is_temp,relation__is_catalog,relation__column_names0.2.3→0.3.0update scriptpg_upgradecoverage across update origins, including a stepwise every-major climb, plus enum-mapping and relkind test helpers