On Sat, Jul 25, 2026 at 2:10 AM Andreas Karlsson <andreas@proxel.se> 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.
