Support object OWNER changes or diagnose ignored ownership intent #602

Summary

With pgschema 1.13.0 and PostgreSQL 18.4, a desired SQL file containing only an object-owner change produces a successful empty plan. The target object's owner stays unchanged. This was observed independently for a table, view, function, and standalone sequence.

This is a request to support ownership reconciliation, or explicitly diagnose unsupported OWNER TO statements. I understand that cluster/database-level objects are outside the documented scope; these examples change the owner of an existing schema-level object, with all roles already provisioned.

Reproduction

The following is a standalone form of the tested synthetic table case. Use a fresh disposable PostgreSQL 18.4 cluster with local authentication configured for these test roles. Supply passwords via your normal environment/password file if required. The setup creates roles and two databases; roles are prerequisites, not part of the desired schema.

export PGHOST=localhost PGPORT=5432 PGSSLMODE=disable
psql -X -v ON_ERROR_STOP=1 -U postgres -d postgres <<'SQL'
CREATE ROLE eval_owner LOGIN;
CREATE ROLE eval_other;
GRANT eval_other TO eval_owner;
CREATE DATABASE owner_target OWNER eval_owner;
CREATE DATABASE owner_plan OWNER eval_owner;
SQL

psql -X -v ON_ERROR_STOP=1 -U eval_owner -d owner_target <<'SQL'
GRANT CREATE ON SCHEMA public TO eval_other;
CREATE TABLE public.item(id integer PRIMARY KEY, value integer NOT NULL);
INSERT INTO public.item VALUES (1,10),(2,20);
SQL

psql -X -v ON_ERROR_STOP=1 -U eval_owner -d owner_plan <<'SQL'
GRANT CREATE ON SCHEMA public TO eval_other;
ALTER DEFAULT PRIVILEGES FOR ROLE eval_owner
  GRANT CREATE ON SCHEMAS TO eval_other;
SQL

cat > desired.sql <<'SQL'
CREATE TABLE public.item(id integer PRIMARY KEY, value integer NOT NULL);
ALTER TABLE public.item OWNER TO eval_other;
SQL

pgschema plan --host "$PGHOST" --port "$PGPORT" \
  --db owner_target --user eval_owner --sslmode disable \
  --plan-host "$PGHOST" --plan-port "$PGPORT" \
  --plan-db owner_plan --plan-user eval_owner --plan-sslmode disable \
  --file desired.sql --output-json plan.json --output-sql plan.sql --no-color

psql -X -U eval_owner -d owner_target <<'SQL'
SELECT pg_get_userbyid(relowner) AS actual_owner,
       pg_get_userbyid(relowner) = 'eval_other' AS desired_owner_reached
FROM pg_class WHERE oid = 'public.item'::regclass;
SELECT count(*) = 2 AND sum(value) = 30 AS data_preserved FROM public.item;
SQL

The planning database's default CREATE ON SCHEMAS grant is deliberate: it gives the alternative owner permission on pgschema's temporary schema. The tested case provisioned both role membership and schema CREATE rights before planning. The desired ownership change also succeeded when executed directly in a separate reference database under eval_owner.

Observed result

• plan exits 0, without an ownership diagnostic.
• plan.sql is empty and the JSON plan has "groups": null.
• Applying was skipped because the plan contained no operations.
• actual_owner remains eval_owner; desired_owner_reached is false.
• data_preserved is true.

Other independently tested object types

Each used a fresh target and planning database with the same role/permission setup. For each case, the baseline was the CREATE statement(s), and the desired file added the indicated ALTER statement.

-- View baseline:
CREATE TABLE public.item(id integer PRIMARY KEY, value integer NOT NULL);
CREATE VIEW public.item_view AS SELECT * FROM public.item;
-- Desired adds:
ALTER VIEW public.item_view OWNER TO eval_other;
-- Catalog assertion (false after successful empty plan):
SELECT pg_get_userbyid(relowner) = 'eval_other'
FROM pg_class WHERE oid = 'public.item_view'::regclass;

-- Function baseline:
CREATE FUNCTION public.calculate(x integer) RETURNS integer
LANGUAGE sql IMMUTABLE AS $$ SELECT x+1 $$;
-- Desired adds:
ALTER FUNCTION public.calculate(integer) OWNER TO eval_other;
-- Catalog assertion (false):
SELECT pg_get_userbyid(proowner) = 'eval_other'
FROM pg_proc WHERE oid = 'public.calculate(integer)'::regprocedure;

-- Standalone sequence baseline:
CREATE SEQUENCE public.counter;
-- Desired adds:
ALTER SEQUENCE public.counter OWNER TO eval_other;
-- Catalog assertion (false):
SELECT pg_get_userbyid(relowner) = 'eval_other'
FROM pg_class WHERE oid = 'public.counter'::regclass;

Expected behavior / scope

Generate the corresponding ALTER ... OWNER TO migration and reconcile the catalog owner. If owner management is intentionally unsupported, please flag these statements explicitly instead of returning a successful no-change result, and document that boundary.

This concerns the role owning an object, not ALTER SEQUENCE ... OWNED BY table.column; PR #578 addresses the latter. It also differs from #32, which concerned inspection permission errors on functions/procedures owned by another role.

The execution evidence is for released v1.13.0, using an external PostgreSQL 18.4 planning database. I checked current issues and documentation for related work but have not rerun current main. No production schema or data is included.