PostgreSQL禁用外键约束时是否会同时禁用对应的系统触发器

你的猜测不成立，相关逻辑和可行方案如下：

核心原理说明 #

PostgreSQL的外键约束完全依靠两组系统级RI_前缀触发器实现校验逻辑：

• 子表侧触发器：子表执行插入、更新操作时，校验关联的父表键是否存在
• 父表侧触发器：父表执行删除、更新主键操作时，校验子表是否存在关联遗留数据

你提到的「禁用外键约束」在PostgreSQL原生语法中没有对应直接操作，若想通过禁用触发器的方式跳过外键校验，这两类RI_触发器均属于系统触发器范畴，仅SUPERUSER有权限执行禁用操作，不存在「禁用子表外键就自动让父表对应系统触发器失效」的逻辑。

无需SUPERUSER的可行方案 #

你提到的「临时删除外键+事后重建」是最稳妥的实现方式，操作步骤如下：

1. 先导出应用schema下所有外键约束的定义，用于后续重建，执行以下SQL即可：

SELECT pg_get_constraintdef(c.oid) 
FROM pg_constraint c 
JOIN pg_namespace n ON c.connamespace = n.oid 
WHERE n.nspname = '你的应用schema名称' 
  AND c.contype = 'f';

2. 批量删除所有外键约束，仅需表所有者权限即可执行
3. 执行数据加载/调整任务
4. 用第一步导出的约束定义批量重建外键即可

如果表数据量较大，为了减少重建约束时的锁表时间，可以采用两步创建法：

1. 先创建不做全量校验的约束：
   ALTER TABLE 子表名 ADD CONSTRAINT 外键约束名 FOREIGN KEY (关联列) REFERENCES 父表名(关联列) NOT VALID;
2. 后台异步执行全量校验，校验过程不会阻塞表的正常读写：
   ALTER TABLE 子表名 VALIDATE CONSTRAINT 外键约束名;

内容的提问来源于stack exchange，提问作者DaveR