Hi, On Tue, Jun 18, 2024 at 8:25 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Ashutosh Sharma <ashu.coe...@gmail.com> writes: > > On Tue, Jun 18, 2024 at 7:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I think the assertion you noticed is there because the code path gets > >> traversed during REINDEX, which is an operation we do support on > >> system catalogs. I have zero interest in making truncate work > >> on them. > > > I agree with you on that point. How about considering a complete > > restriction instead? > > You already broke the safety seal by enabling allow_system_table_mods. > Perhaps the documentation of that is not scary enough? > > Allows modification of the structure of system tables as well as > certain other risky actions on system tables. This is otherwise not > allowed even for superusers. Ill-advised use of this setting can > cause irretrievable data loss or seriously corrupt the database > system. >
I was actually referring to just the truncation part here, not any DML operations, as I've observed their usage in certain extensions. However, truncation is just used for pg_largeobject and that too only during pg_upgrade, so for other catalogs truncation can be avoided. But that is just my perspective; if it's not essential, we can possibly stop this discussion here. Thank you to everyone for sharing your valuable insights. -- With Regards, Ashutosh Sharma.
