2BP01 dependent_objects_still_exist

速览

2BP01 表示 DROP 或相关目录操作要移除的对象仍被其他数据库对象依赖。正确处理是先理解依赖关系，决定依赖对象应保留还是删除，再重试原操作。

含义

依赖遍历器会在对象仍被其他对象需要时发出 2BP01。代表路径中视图依赖表，因此 DROP TABLE 不能执行。主报文、DETAIL 和 CASCADE 提示都根据对象描述和依赖图动态组装。2BP01 讨论的是依赖对象；依赖权限描述符的 2B000 是另一种条件。

诊断

同时保存 SQLSTATE、主报文、DETAIL 和 HINT。选定路径的 DETAIL 会指出依赖视图。选择修复前检查视图定义和依赖元数据；pg_depend 与 pg_get_viewdef() 可以说明对象为什么仍被保留。在选定的显式 BEGIN 块中，收到该 ERROR 后连接会在 ROLLBACK 前处于 INERROR；自动提交语句没有需要保留的外层事务。不能在失败的显式块中继续查询目录来完成可靠诊断。

处理

先回滚失败的显式事务。如果视图确实可以删除，先删视图，再删表；如果视图属于模式契约，就保留它并改写迁移方案。CASCADE 是删除依赖对象的明确请求，可能超过预期变更，因此不能把 HINT 自动当成执行指令。完成有边界的修复后，重新执行完整 DDL 计划并核对仍应存在的对象。

报文

选定源码分支的模板为 cannot drop %s because other objects depend on it，DETAIL 是动态内部文本，HINT 为 Use DROP ... CASCADE to drop the dependent objects too.。对象描述和依赖列表都是运行时值，不要把 DETAIL 当成固定的单对象模板，也不要假设所有 2BP01 路径都使用同一措辞。

代表案例

运行器从 verify/cases/2BP01/snippets.json（SHA-256 899e4fd9fb002fc293bd9efee0204e4f2622968c6d9460ad05eb9a0ebd3bac69）读取下面的依赖序列；失败 DROP 使用显式 BEGIN/ROLLBACK，修复先删已知视图再删表，完全不使用 CASCADE。见公开案例导出和结构化证据。

CREATE TABLE base_items(id integer PRIMARY KEY, payload text NOT NULL);
CREATE VIEW dependent_view AS SELECT id, payload FROM base_items;
BEGIN;
DROP TABLE base_items;
ROLLBACK;
DROP VIEW dependent_view;
DROP TABLE base_items;
SELECT to_regclass('base_items'), to_regclass('dependent_view');

运行器会在私有 schema 中为 registry 名称加限定名。最后两个 to_regclass 都返回 null，证明删除的是预期对象，而不是对未知依赖图静默级联。

选定案例在 PostgreSQL 18.6 和 10.21 观察到 2BP01。DROP TABLE 的 DETAIL 指出依赖视图并给出 CASCADE 提示；显式事务进入 INERROR，ROLLBACK 恢复为 IDLE，随后先删视图再删表完成修复。

版本

目录从早期历史边界到正式快照都记录了该条件。18.6 固定源码还包括依赖、共享依赖、角色、权限、类型表和表空间等分支；运行案例只覆盖 18.6 与 10.21 的普通视图到表依赖。不能据此推断所有分支的 CASCADE 都安全。

相关

可对照2B000 依赖权限描述符仍存在和42P01 表不存在。

来源

• 上游源码 doc/src/sgml/ref/drop_table.sgml REL_18_6 724edf9bd 0eddfa55
• 上游源码 src/backend/catalog/dependency.c 第 1148–1154 行 REL_18_6 724edf9bd 1878f848
• 上游源码 src/backend/utils/errcodes.txt REL_18_6 724edf9bd 6e8de346
• 核验材料 raw/calls/REL_18_6.jsonl 9ee8a0e8