From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug on drop extension dependencies ? |
Date: | 2025-07-13 15:19:47 |
Message-ID: | 269091.1752419987@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> writes:
> 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.
[ shrug... ] We do report that. For example:
regression=# create table t1(f1 int primary key);
CREATE TABLE
regression=# create table t2(f2 int references t1);
CREATE TABLE
regression=# drop table t1;
ERROR: cannot drop table t1 because other objects depend on it
DETAIL: constraint t2_f2_fkey on table t2 depends on table t1
HINT: Use DROP ... CASCADE to drop the dependent objects too.
regression=# drop table t1 cascade;
NOTICE: drop cascades to constraint t2_f2_fkey on table t2
DROP TABLE
At default log settings, the ERROR/DETAIL would appear in the log,
while the NOTICE would not. Either way, there is plenty of
opportunity to observe what will or did get dropped.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zhang Mingli | 2025-07-13 15:37:07 | Re: [Question] Window Function Results without ORDER BY Clause |
Previous Message | Florents Tselai | 2025-07-13 15:08:27 | Re: add function for creating/attaching hash table in DSM registry |