On Sat, Jul 25, 2026 at 2:10 AM Andreas Karlsson <[email protected]> wrote: > > On 7/2/26 2:55 AM, surya poondla wrote: > > The patch adds contrib/pgtrashcan: a new extension that intercepts DROP > > TABLE via a ProcessUtility hook and moves the relation to a > > reserved schema instead of destroying it, from where it can be restored > > with pgtrashcan_restore or permanently deleted with > > pgtrashcan_purge. It is a fork of an existing pgtrashcan extension, > > extended with additional features. > > > > Any feedback is welcome. > > Is there any reason your features cannot be added to the existing > extension? Or that extension to be forked but still live outside core > PostgresSQL? >
The one argument I see for keeping such a feature in-tree is that it touches a number of subsystems that evolve with core and would need coordinated review: dependency handling and CASCADE (foreign keys, views, etc.), pg_dump/pg_upgrade treatment of the reserved schema and the objects parked in it, event triggers, triggers that reference other relations, and interaction with logical/DDL replication. These interactions are subtle and can change over time, so maintaining them alongside core might be easier in the tree than chasing core from outside. On the other hand, I'm not sure if it's a good idea to protect only DROP TABLE and not the other paths like DROP SCHEMA ... CASCADE, DROP OWNED, etc., as pointed out by Zsolt. I think we should first decide whether such a feature is useful enough to add to core, and then work out the appropriate design to accomplish it. Surya's initial email lists use cases that sound reasonable, and several other databases do support this, but not sure those are enough to justify making it a core feature. -- With Regards, Amit Kapila.
