Marcos Pegoraro <marcos@f10.com.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
