On Thu, Sep 24, 2026 at 11:28:54AM -0300, Manu wrote: >> On top of that, a just dropped schema can still be used to create >> temporary objects, which creates a pg_class orphan: >> IIUC the problem is that activeCreationNamespace is used when the >> relpersistence is not RELPERSISTENCE_TEMP. So with pg_temp first in >> search_path, activeCreationNamespace is the dropped schema.
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. 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. > That's right, and 0002 does not cover it, nor does my diff on top of > it. I ran each kind of CREATE as the first statement after the drop, > with pg_temp first in search_path and no TEMP keyword, one fresh > cluster per statement, on master and with 0001+0002 (the rollback diff > gives the same results): This comment does not apply only to this thread, more to the recent activities of this email address: note that most of your reviews, being clearly AI-generated, are rather noisy (not all, but a large majority), and sometimes miss the point while providing a sloppy amount of confusing contents. -- Michael
signature.asc
Description: PGP signature
