with check option 能阻止非法插入，但仅限通过视图执行的 insert/update 操作，强制新数据满足视图 where 条件，不满足则报错且基表无写入；它不约束直接操作基表或不可更新视图。
WITH CHECK OPTION 是什么，它真能阻止非法插入吗？
能，但只在视图上生效，且仅当插入操作经过该视图时才起作用。它不是表级约束，不会影响直接对基表的 INSERT。它的本质是：**每次通过视图执行 INSERT 或 UPDATE 时，强制校验新数据是否仍满足视图定义中的 WHERE 条件**。不满足就报错，比如 ERROR: new row violates check option for view。
创建带 WITH CHECK OPTION 的视图要避开哪些坑？
常见错误是忽略视图定义的“可更新性”前提——视图必须是简单可更新的（不能含 DISTINCT、聚合、GROUP BY、多表 JOIN 等）。否则即使加了 WITH CHECK OPTION，PostgreSQL 也会拒绝创建，报错 cannot create a checked view with this definition。
- 只对单表投影 + 简单
WHERE的视图有效，例如：CREATE VIEW active_users AS SELECT * FROM users WHERE status = 'active' WITH CHECK OPTION;
- 如果视图里用了
SELECT id, name FROM users WHERE status = 'active'（没选所有列），插入时未提供被省略的列（如status）会导致默认值或NULL冲突，即便满足WHERE条件也可能失败 - MySQL 要求显式写成
WITH LOCAL CHECK OPTION或WITH CASCADED CHECK OPTION；PostgreSQL 只支持WITH CHECK OPTION（等价于CASCADED）
为什么 INSERT INTO view VALUES (...) 有时不触发检查？
根本原因是：你可能没走视图路径。比如视图基于 users 表，但你执行的是 INSERT INTO users (...) VALUES (...) —— 这完全绕过视图和它的 WITH CHECK OPTION。另外，某些 ORM 或客户端工具会自动展开视图查询，把语句重写为对基表的操作，此时约束失效。
- 确认执行的是
INSERT INTO active_users (...) VALUES (...)，而非基表名 - 在 PostgreSQL 中可用
\d+ active_users查看视图定义，确认末尾有with check option字样 - 若视图嵌套（A 视图基于 B 视图），
CASCADED会逐层检查；LOCAL（MySQL）只检查当前视图条件，不递归
用 WITH CHECK OPTION 防止状态越权修改的实际效果
这是它最典型的用途：限制用户只能操作符合业务状态的数据子集。比如财务系统中，只允许插入 status = 'pending' 的报销单，但禁止直接插成 'approved'。
- 假设视图定义为：
CREATE VIEW pending_expenses AS SELECT * FROM expenses WHERE status = 'pending' WITH CHECK OPTION;
- 执行
INSERT INTO pending_expenses (amount, description, status) VALUES (1000, 'lunch', 'approved')会失败，因为新行不满足status = 'pending' - 但如果插入时不指定
status，而表定义中该字段有默认值（如DEFAULT 'draft'），则可能因默认值不匹配视图条件而失败——这点常被忽略
真正起作用的不是语法本身，而是你是否让所有写入流量严格收敛到该视图入口，并确保视图定义足够精确、无歧义。漏掉一个直连基表的脚本，整个约束就形同虚设。
