On Wed, May 6, 2026 at 3:01 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Wed, May 6, 2026 at 9:24 AM vignesh C <vignesh21@gmail.com> 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.
