Re: [DESIGN] Soft DROP TABLE, recoverable drops for PostgreSQL

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Andreas Karlsson" <andreas(at)proxel(dot)se>
Cc: "surya poondla" <suryapoondla4(at)gmail(dot)com>, "L(dot) pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [DESIGN] Soft DROP TABLE, recoverable drops for PostgreSQL
Date: 2026-07-25 08:42:16
Message-ID: a17ec068-c800-484c-8495-ee4bf7b56e47@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-07-25, Amit Kapila wrote:

> 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 wonder if this would be better implemented as an sql_drop event trigger. Then all these things are covered.

--
Álvaro Herrera

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-07-25 09:22:55 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup
Previous Message Álvaro Herrera 2026-07-25 07:07:26 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup