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@maxcontact.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.