旧版SQL触发器不能直接升级，必须重构为函数+触发器两步：MySQL内联逻辑需拆解为PL/pgSQL函数并绑定；SQL Server的INSTEAD OF触发器须适配视图限制与行级处理；迁移后需重点验证排序规则、时间精度及权限链。
旧版 SQL 触发器不能直接“升级”到新版数据库，必须重写。不是语法微调，而是模型重构——尤其是从 MySQL 或 SQL Server 迁到 PostgreSQL 时，CREATE TRIGGER 语句本身几乎没用，真正要动的是函数定义和执行上下文。
MySQL 触发器迁到 PostgreSQL：必须拆成函数 + 触发器两步
MySQL 允许在 CREATE TRIGGER 里直接写逻辑（比如 BEGIN ... INSERT INTO logs ... END），PostgreSQL 不接受这种写法。你得先用 CREATE FUNCTION 定义行为，再用 CREATE TRIGGER 绑定它。
- 触发器体必须是独立函数，语言通常是
plpgsql，不能是内联 SQL -
OLD和NEW仍可用，但访问方式略有不同：比如NEW.username而不是NEW.username（注意大小写敏感，PostgreSQL 默认小写） - 异常抛出要用
RAISE EXCEPTION 'xxx'，不是SIGNAL SQLSTATE - 如果原触发器用了游标或循环，PostgreSQL 的
FOR record IN SELECT ... LOOP写法更严格，需显式声明record类型
SQL Server 触发器迁到 PostgreSQL：注意 INSTEAD OF 和多行处理
SQL Server 的 INSTEAD OF 触发器在 PostgreSQL 中同样支持，但行为边界更窄；更重要的是，SQL Server 默认按语句级批量处理（inserted/deleted 表可含多行），而 PostgreSQL 默认是行级（FOR EACH ROW），若没加 FOR EACH STATEMENT，逻辑会错位。
- 原 SQL Server 中对
inserted表的集合操作（如SELECT COUNT(*) FROM inserted），在 PostgreSQL 中需改用FOR EACH STATEMENT+ 临时表或聚合变量 -
INSTEAD OF触发器只能建在视图上，不能建在普通表上——这点和 SQL Server 不同，别硬套 - SQL Server 的
@@ROWCOUNT在 PostgreSQL 中没有等价物，需用GET DIAGNOSTICS row_count = ROW_COUNT替代 - 事务控制（如
ROLLBACK）不能出现在触发器函数里，PostgreSQL 禁止在函数中执行事务命令
跨数据库迁移触发器时最容易漏掉的三件事
功能看似跑通了，但上线后出问题，往往卡在这三个隐性环节：
- 字符集与 collation：MySQL 的
utf8mb4_unicode_ci和 PostgreSQL 的en_US.utf8排序规则不等价，触发器里做字符串比较（比如IF NEW.name = 'admin'）可能因排序差异失效 - 时间类型处理：MySQL 的
NOW()在 PostgreSQL 中对应CURRENT_TIMESTAMP，但精度默认不同（microsecond vs millisecond），若触发器依赖毫秒级判断，得显式写成CURRENT_TIMESTAMP(6) - 权限链断裂：PostgreSQL 触发器函数默认以定义者（
SECURITY DEFINER）运行，但如果函数里调用了其他 schema 下的表，必须显式GRANT SELECT ON xxx TO public或指定角色，否则报permission denied for table
触发器迁移最耗时的从来不是语法转换，而是验证——它不报错，但可能在某条特定数据路径下静默跳过逻辑。上线前务必用真实业务流水覆盖所有 OLD/NEW 组合、空值、边界长度、并发更新场景，别只测单条 INSERT。
