Re: Bug on drop extension dependencies ?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug on drop extension dependencies ?
Date: 2025-07-13 15:38:40
Message-ID: CAKFQuwaE62njLgNgQpo+vn_LVPSPW+ihn--RQHkFu=Yg+TSpfw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sunday, July 13, 2025, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:

> Em sáb., 12 de jul. de 2025 às 16:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> escreveu:
>
>> Indeed. If we put a restriction on this case then we'd just need to
>> invent a "REALLY CASCADE" option that did the more aggressive thing.
>>
>
> I understand that it's not possible to prevent DROP ... CASCADE from
> executing. However, the subsequent deletion of constraints, triggers, or
> functions will affect the behavior of other schemas, so I think it's
> reasonable to at least explicitly state in the log which objects were
> deleted due to that command.
>

Then install an event trigger and log every object that gets dropped at any
time.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-07-13 15:39:04 Re: [PATCH] replace float8 with int in date2isoweek() and date2isoyear()
Previous Message Zhang Mingli 2025-07-13 15:37:07 Re: [Question] Window Function Results without ORDER BY Clause