On Wed, May 6, 2026 at 3:01 PM shveta malik <[email protected]> wrote: > > On Wed, May 6, 2026 at 9:24 AM vignesh C <[email protected]> wrote: > > > > Few comments: > > 1) Currently we allow renaming of pg_conflict schema, this might be ok > > as we allow other sysem schema like pg_catalog and pg_toast also. > > postgres=# alter schema pg_conflict rename to test_conflict; > > ALTER SCHEMA > > > > I agree that we allow renaming other schemas including pg_toast, but I > am not sure if this is consciously made decision, see BUG #18281 ast > [1]. I don't favour allowing renaming pg_conflict for 2 reasons: > > 1) Because Postgres explicitly blocks renaming schemas to a name > starting with 'pg_'. If an admin accidentally renames 'pg_conflict' to > something else, they are permanently locked out from renaming it back. > > 2) While the core worker might survive a rename via OID lookups; > external scripts, extensions, and monitoring tools will likely > hardcode the 'pg_conflict' string. If the schema is renamed, these > tools will fail. >
I think we shouldn't go out of our way to disallow superusers to rename pg_conflict schema similar to other cases. We can try to prevent hard-coding schema names where possible but not sure we can guarantee that nothing related to pg_conflict schema won't break as shown by you in the following similar case for pg_conflict. > One such example of scripts breaking is present event in Postgres. I > did the following, and most of psql commands started failing after > that due to hard-coded pg_catalog name in them. > > postgres=# alter schema pg_catalog rename to catalog_new; > ALTER SCHEMA > > postgres=# \d catalog_new.* > ERROR: relation "pg_catalog.pg_class" does not exist > LINE 5: FROM pg_catalog.pg_class c > > [1]: > https://www.postgresql.org/message-id/flat/18281-5b1b6c5991d345aa%40postgresql.org > -- With Regards, Amit Kapila.
