Hi all, thanks for testing and commenting. On Fri, Sep 25, 2026 at 3:48 AM Michael Paquier <[email protected]> wrote: > All these actions are doable only under a superuser, and there is an > argument over the existing behavior being useful, for example to clean > up orphaned objects post-crash-recovery. > > Superusers can do worse than that. For example issue a TRUNCATE on a > few catalogs like pg_database, with set allow_system_table_mods = > true. Now, that's much more interesting.
In that case the superuser is opting-in to something explicitly dangerous. > My point being: we did not care back then for the reasons given back > then related to superusers. Why should we care now? This discussion > was feeling as a waste of precious resources back then; it still feels > the same today. I wasn't aware of those discussions, but unlike above, DROP SCHEMA pg_temp_N looks innocent enough, yet it can break pg_dump (not to mention the segfault) which seemed severe enough to me to warrant a fix. Still if this is the consensus I don't mind leaving that as is. That said I do think that the first part of the patch (0001, which fixes the two identify-object functions) has merit on its own. If nothing else, then at least to gracefully handle the existing behavior for temp schema drops. I can post it separately with a regression test if there's interest. Thanks, Marko
