MySQL触发器无法直接迁移到PostgreSQL，因二者模型本质不同：MySQL支持内联逻辑，PostgreSQL必须先定义函数再绑定触发器，且语法、变量访问、错误处理、级别声明等均需重构。
MySQL 触发器不能直接迁移到其他数据库，尤其是 PostgreSQL —— 因为两者触发器模型本质不同：MySQL 允许内联逻辑，PostgreSQL 要求先定义函数再绑定触发器。迁移不是替换关键字，而是重构执行逻辑。
为什么直接复制 CREATE TRIGGER 会报错
你粘贴 MySQL 的 CREATE TRIGGER ... BEGIN ... END 到 PostgreSQL，大概率遇到：ERROR: syntax error at or near "BEGIN" 或 function ... does not exist。原因很实在：
- PostgreSQL 不支持在
CREATE TRIGGER里写内联 SQL 块，必须指向一个已存在的函数 - MySQL 的
OLD/NEW在 PostgreSQL 中可用，但访问方式受函数语言限制（比如 PL/pgSQL 中要写成OLD.column_name） - MySQL 的
SIGNAL SQLSTATE在 PostgreSQL 中得换成RAISE EXCEPTION，且错误码映射不自动 - MySQL 触发器默认是行级（
FOR EACH ROW），而 PostgreSQL 明确要求声明FOR EACH ROW或FOR EACH STATEMENT，漏写就语法报错
PostgreSQL 触发器迁移的最小可行步骤
以 MySQL 中一个简单的审计日志触发器为例：
-- MySQL 原始触发器
CREATE TRIGGER trg_after_update_users
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
INSERT INTO audit_log (table_name, action, updated_at)
VALUES ('users', 'UPDATE', NOW());
END;
迁到 PostgreSQL 需三步，缺一不可：
- 用
CREATE OR REPLACE FUNCTION定义一个 PL/pgSQL 函数，里面写插入逻辑，返回TRIGGER - 函数体内用
NEW或OLD访问行数据，时间用CURRENT_TIMESTAMP（不是NOW()，虽然后者也兼容，但语义更清晰） - 再用
CREATE TRIGGER绑定该函数，显式写上FOR EACH ROW EXECUTE FUNCTION function_name()
容易被忽略的兼容性细节
这些点不报错但会导致行为偏差，上线后才暴露：
BEFORE UPDATE触发器中，MySQL 允许直接赋值给NEW.column = ...；PostgreSQL 同样支持，但必须确保函数返回NEW（否则更新会被丢弃）- MySQL 触发器可引用同一张表的其他字段做计算，PostgreSQL 函数里也能，但要注意：如果触发器是
AFTER，NEW是最终值；如果是BEFORE，改了NEW才会影响实际写入 - MySQL 没有
INSTEAD OF触发器，但 PostgreSQL 支持——如果你迁的是视图上的触发器，这是唯一能实现“拦截并重写操作”的方式 - 触发器执行顺序：MySQL 按名称字母序，PostgreSQL 默认无序；如需控制先后，得靠函数内部逻辑或用
pg_trigger_depth()防递归
要不要用工具自动转换？
像ora2pg（MySQL适配版）或pgloader这类工具，处理表结构和数据是没问题的，但它们对触发器逻辑是“两眼一抹黑”，根本不解析也不转换。官方文档说得明白：触发器得人工重写。为啥呢？因为SQL逻辑里可能藏着业务规则、跨表查询、条件分支这些复杂玩意儿，工具可没办法安全地推断出它们的语义。可别信那些“一键迁移触发器”的宣传，那通常就是把语法块原封不动地注释掉或者留个空壳而已。
