PostgreSQL维护分组position列的触发器有哪些潜在问题和副作用？

• 并发冲突风险高：同一分类下同时执行插入、更新位置操作时，事务查询分类下总记录数_count和实际写入之间存在时间差，即使有唯一约束兜底也会大量出现事务报错回滚，高并发场景下基本不可用，需要对操作的分类加行级锁才能避免该问题。
• 删除操作性能极差：AFTER DELETE触发器是行级触发，每删除一条就会全量重写当前分类下所有行的position值，如果分类下有数千甚至上万条记录，单次删除操作都会引发大量IO，要是批量删除同分类多条记录，会重复执行N次全分类重排，性能会直接雪崩。
• 全局修改约束延迟存在溢出风险：触发器里SET CONSTRAINTS ALL DEFERRED是修改当前整个事务的所有约束行为，会影响同事务内其他表的约束校验逻辑，比如其他表原本配置为立即校验的唯一、外键约束都会变成延迟校验，不符合其他业务逻辑的预期，正确做法应该只延迟当前表的(category_id, position)唯一约束。
• 批量操作支持差：如果用INSERT INTO ... SELECT批量插入同分类多条记录，或者批量更新多条记录的position，行级触发器会逐行触发重排逻辑，每次都更新中间行的position，不仅执行效率极低，还可能出现计数错误导致位置重复。
• 未处理category_id更新场景：当前触发器仅监听UPDATE OF position，如果修改某行的category_id值，原分类会出现position空洞，新分类也不会自动重排位置，逻辑存在遗漏。
• 嵌套触发判断的边界问题：用pg_trigger_depth() = 0避免循环触发的逻辑，在存在其他触发器联动修改当前表数据的场景下，会跳过position重排逻辑，导致位置出现空洞或者重复。

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