PostgreSQL中DROP COLUMN报“depends on it”需先查依赖视图再处理：用pg_depend定位引用该列的视图，手动重建或替换；CASCADE虽快但会级联删除依赖对象，风险高。
PostgreSQL 中 DROP COLUMN 报 “depends on it” 怎么办
这是 PostgreSQL 主动保护依赖关系的结果，不是错误，也不是权限或语法问题。只要视图定义里显式写了该列名（比如 SELECT id, name, old_col FROM users），或者用了 SELECT * 且该列当时存在，ALTER TABLE DROP COLUMN 就会直接中止并报错。
常见误判点：Navicat 或 DBeaver 界面点“删除列”没立刻报错，不代表执行成功——真正执行时仍触发内核级校验。
- CASCADE 最快但危险：会连带删掉所有依赖该列的视图、索引、约束、触发器，嵌套视图可能引发连锁删除
- 手动清理更可控：先查出哪些视图引用了该列，再逐个重建或替换。用这条语句定位：
SELECT DISTINCT referencing_schema_name, referencing_entity_name, referencing_class_desc
FROM sys.sql_expression_dependencies -- SQL Server
WHERE referenced_id = OBJECT_ID('dbo.users') AND referenced_minor_id = COLUMNPROPERTY(OBJECT_ID('dbo.users'), 'old_col', 'ColumnId');⚠️ 注意：上面是 SQL Server 写法；PostgreSQL 应查 pg_depend 和 pg_views，实际推荐用：
SELECT v.schemaname, v.viewname FROM pg_views v, pg_class c, pg_attribute a, pg_depend d WHERE v.oid = c.oid AND c.oid = a.attrelid AND c.oid = d.refobjid AND a.attnum = d.refobjsubid AND a.attname = 'old_col' AND d.classid = 'pg_class'::regclass AND d.refclassid = 'pg_class'::regclass;
MySQL 视图因基表列缺失导致 DROP VIEW 失败
ERROR 1356 不是权限问题，是 MySQL 在删视图前会隐式重编译定义——一旦发现 SELECT 里的列在基表中已不存在，就拒绝删除。
典型场景包括：基表被 ALTER TABLE ... DROP COLUMN 了，或字段重命名后没同步改视图定义。
- 先确认视图是否还“合法”：
SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'v_name';，看VIEW_DEFINITION字段里有没有可疑列名 - 再查它到底依赖哪些列：
SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.VIEW_COLUMN_USAGE WHERE VIEW_SCHEMA = 'db_name' AND VIEW_NAME = 'v_name'; - 如果返回空或报错，说明依赖已断；此时不能硬删，得先用
CREATE OR REPLACE VIEW覆盖成一个合法定义（比如SELECT 1 AS dummy），再执行DROP VIEW
SQL Server 视图列元数据失效但 sp_refreshview 不起作用
sp_refreshview 只更新列的元数据（system_type_id、max_length、是否可空），完全不碰 FROM 子句里的表名、列名、JOIN 条件。基表删了一列，它照样执行成功，但后续查询直接崩。
必须重建视图的硬性信号：
- 视图定义含
SELECT *，而基表删了列 → 查询时报 “Invalid column name” - 基表列类型从
INT（system_type_id = 56）改成BIGINT（system_type_id = 127），且视图里有算术表达式 → 类型隐式转换可能溢出，sp_refreshview不修复逻辑 - 基表重命名或跨 schema 移动（如从
dbo.users改成core.users）→sp_refreshview完全无感，执行后仍报 “Invalid object name”
重建前务必比对 system_type_id 和 max_length，不能只看列名一致就认为类型兼容。
重建视图前必须验证的三件事
视图不是独立对象，它是活的依赖链节点。删列、改名、迁移 schema 都可能让下游视图静默失效——直到某次报表跑批或 BI 查询才暴露。
- 检查该视图是否被其他视图/函数/存储过程引用：SQL Server 查
sys.sql_expression_dependencies，MySQL 查INFORMATION_SCHEMA.VIEWS的VIEW_DEFINITION字段 - 确认当前用户对目标视图有
VIEW DEFINITION权限（SQL Server）或SHOW VIEW权限（MySQL），否则SELECT或SHOW CREATE VIEW都会失败 - 执行一次
SELECT TOP 1 * FROM [view_name]（SQL Server）或SELECT * FROM view_name LIMIT 1（MySQL），验证它还能跑通——很多“失效”视图其实早就不能 SELECT 了，只是没人试过
最常被忽略的一点：视图定义里没带 schema 前缀（比如写 CREATE VIEW vw_user AS SELECT ... FROM users），结果基表在 dbo，而当前 session 的默认 schema 是 app，就会查不到表。重建时务必显式写全 dbo.users。
