fix: incorporate v3.0.0 supautils

with change that checks that an event trigger function is owned by the same superuser
negating the need for after-create for postgresql_fdw
introduces a test in pg_regress that checks the outcome of this change

Author: samrose

ansible/files/postgresql_extension_custom_scripts/postgres_fdw/after-create.sql

@@ -10,9 +10,9 @@ postgres_major:
 
 # Full version strings for each major version
 postgres_release:
-  postgresorioledb-17: "17.5.1.043-orioledb"
-  postgres17: "17.6.1.022"
-  postgres15: "15.14.1.022"
+  postgresorioledb-17: "17.5.1.044-orioledb-supautils-1"
+  postgres17: "17.6.1.023-supautils-1"
+  postgres15: "15.14.1.023-supautils-1"
 
 # Non Postgres Extensions
 pgbouncer_release: 1.19.0

ansible/vars.yml

@@ -7,15 +7,15 @@
 
 stdenv.mkDerivation rec {
   pname = "supautils";
-  version = "2.9.4";
+  version = "3.0.0";
 
   buildInputs = [ postgresql ];
 
   src = fetchFromGitHub {
     owner = "supabase";
     repo = pname;
     rev = "refs/tags/v${version}";
-    hash = "sha256-qP9fOEWXw+wY49GopTizwxSBEGS0UoseJHVBtKS/BdI=";
+    hash = "sha256-EKKjNZQf7HwP/MxpHoPtbEtwXk+wO241GoXVcXpDMFs=";
   };
 
   installPhase = ''

nix/ext/supautils.nix

@@ -0,0 +1,50 @@
+/*
+
+Test to verify supautils (v3.0.0+) allows non-superuser postgres role to own FDWs.
+
+This test ensures that the supautils extension properly handles FDW ownership
+for the privileged postgres role without requiring temporary superuser privileges.
+
+This verifies the fix that eliminated the need for:
+ansible/files/postgresql_extension_custom_scripts/postgres_fdw/after-create.sql (removed)
+
+*/
+BEGIN;
+-- Switch to the postgres role (non-superuser) to test supautils behavior
+SET ROLE postgres;
+-- Test 1: Create a custom FDW directly (this is what supautils v3.0.0 fixes)
+-- Before v3.0.0, this would fail because only superusers can create FDWs
+-- With v3.0.0, supautils allows postgres (privileged role) to create and own FDWs
+CREATE FOREIGN DATA WRAPPER test_fdw_postgres_owned;
+-- Reset to original role for queries because the tests run under a superuser context
+RESET ROLE;
+-- Verify that the custom FDW is owned by postgres (non-superuser)
+SELECT
+  fdw.fdwname as fdw_name,
+  owner.rolname as owner_name,
+  owner.rolsuper as owner_is_superuser
+FROM
+  pg_foreign_data_wrapper fdw
+  JOIN pg_roles owner ON fdw.fdwowner = owner.oid
+WHERE
+  fdw.fdwname = 'test_fdw_postgres_owned';
+        fdw_name         | owner_name | owner_is_superuser 
+-------------------------+------------+--------------------
+ test_fdw_postgres_owned | postgres   | f
+(1 row)
+
+-- Verify the postgres role's superuser status
+-- The key test: postgres should NOT be a superuser, yet can own the FDW
+SELECT
+  rolname,
+  rolsuper as is_superuser
+FROM
+  pg_roles
+WHERE
+  rolname = 'postgres';
+ rolname  | is_superuser 
+----------+--------------
+ postgres | f
+(1 row)
+
+ROLLBACK;

nix/tests/expected/postgres_fdw.out

@@ -0,0 +1,47 @@
+/*
+
+Test to verify supautils (v3.0.0+) allows non-superuser postgres role to own FDWs.
+
+This test ensures that the supautils extension properly handles FDW ownership
+for the privileged postgres role without requiring temporary superuser privileges.
+
+This verifies the fix that eliminated the need for:
+ansible/files/postgresql_extension_custom_scripts/postgres_fdw/after-create.sql (removed)
+
+*/
+
+BEGIN;
+
+-- Switch to the postgres role (non-superuser) to test supautils behavior
+SET ROLE postgres;
+
+-- Test 1: Create a custom FDW directly (this is what supautils v3.0.0 fixes)
+-- Before v3.0.0, this would fail because only superusers can create FDWs
+-- With v3.0.0, supautils allows postgres (privileged role) to create and own FDWs
+CREATE FOREIGN DATA WRAPPER test_fdw_postgres_owned;
+
+-- Reset to original role for queries because the tests run under a superuser context
+RESET ROLE;
+
+-- Verify that the custom FDW is owned by postgres (non-superuser)
+SELECT
+  fdw.fdwname as fdw_name,
+  owner.rolname as owner_name,
+  owner.rolsuper as owner_is_superuser
+FROM
+  pg_foreign_data_wrapper fdw
+  JOIN pg_roles owner ON fdw.fdwowner = owner.oid
+WHERE
+  fdw.fdwname = 'test_fdw_postgres_owned';
+
+-- Verify the postgres role's superuser status
+-- The key test: postgres should NOT be a superuser, yet can own the FDW
+SELECT
+  rolname,
+  rolsuper as is_superuser
+FROM
+  pg_roles
+WHERE
+  rolname = 'postgres';
+
+ROLLBACK;