Re: [EXT]: Re: BUG #18604: Regression in PostgreSQL 16.4: pg_dump Prevents Essential System Table Modifications

On Sep 6, 2024, at 13:46, Basha <Basha(at)maxcontact(dot)com> wrote:
> Step 2:
> ALTER TABLE pg_catalog.pg_database RENAME TO pg_database_catalog;
>
>
> ALTER TABLE pg_catalog.pg_database_catalog
> OWNER TO postgres;
>
> Step3:
>
> CREATE OR REPLACE VIEW pg_catalog.pg_database
> AS
> SELECT oid,
> datname,
> datdba,
> encoding,
> datlocprovider,
> datistemplate,
> datallowconn,
> datconnlimit,
> datfrozenxid,
> datminmxid,
> dattablespace,
> datcollate,
> datctype,
> daticulocale,
> daticurules,
> datcollversion,
> datacl,
> 1262::oid AS tableoid
> FROM pg_database_catalog
> WHERE 1 = 1 AND has_database_privilege(oid, 'connect'::text);
>
>
> ALTER TABLE pg_catalog.pg_database
> OWNER TO postgres;

You've really stepped outside what is considered supported behavior here. That it worked at all was more accidental than a documented and supported feature. Shadowing system catalogs with views *is* going to break things, and that `allow_system_table_mods` has that potential is documented. I'm sure this is frustrating, but it's extremely unlikely that this will be considered a regression worth undoing a security fix for.