PostgreSQL触发器中通过OLD获取修改前字段值（UPDATE/DELETE可用），NEW获取修改后字段值（INSERT/UPDATE可用）；标准化操作必须在BEFORE触发器中修改NEW，AFTER中修改无效。
触发器里怎么拿到修改前后的字段值
PostgreSQL 触发器函数中，OLD 和 NEW 分别代表更新/删除前、插入/更新后的行记录。想标准化某个字段（比如把 email 统一转小写），必须在 BEFORE INSERT OR UPDATE 触发器里操作 NEW，否则改不动——AFTER 触发器里的 NEW 已不可变，改了也白改。
常见错误是写成 AFTER 然后试图赋值：NEW.email := lower(NEW.email);，这行代码根本不会生效，PostgreSQL 会静默忽略。
实操建议：
- 只用
BEFORE INSERT OR UPDATE类型触发器做字段标准化 - 对
UPDATE操作，检查OLD.field IS DISTINCT FROM NEW.field再处理，避免无谓计算 - 如果字段允许 NULL，
lower(NULL)还是 NULL，不用额外判空
标准化逻辑该写在触发器函数里还是用表达式索引
触发器函数负责「写入时强制修正」，表达式索引（如 CREATE INDEX ON users (lower(email));）只管「查询加速」，两者不冲突但职责不同。如果你只要查得快，不用触发器；但要确保表里存的值本身就是小写、去空格、统一格式，就必须靠触发器在入库前改 NEW。
容易踩的坑：
- 只建了
lower(email)索引，却没在触发器里调lower()，结果表里依然存着混杂大小写的 email，索引效果打折 - 用
REGEXP_REPLACE做复杂清洗（如删掉邮箱里的点号），记得在触发器里同步执行，否则应用层和数据库层行为不一致 - 触发器函数里别用
SELECT ... INTO查其他表做标准化（比如根据国家码补全电话前缀），会拖慢写入且可能死锁
如何安全地给已有数据批量标准化并启用触发器
直接加触发器会导致后续所有 INSERT/UPDATE 被拦截修正，但历史数据不会自动更新。必须分两步：先批量修正存量，再启用触发器。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
操作顺序不能错：
- 先用
UPDATE users SET email = lower(email) WHERE email IS NOT NULL;批量清洗 - 确认无误后，再创建触发器函数和触发器对象
- 上线前在测试库用
EXPLAIN ANALYZE INSERT ...看触发器是否引入明显延迟
注意：如果表很大，UPDATE 可能锁表或产生巨量 WAL。可分批更新，例如：UPDATE users SET email = lower(email) WHERE id BETWEEN 10000 AND 19999 AND email IS NOT NULL;
触发器报错 “cannot insert or update column” 怎么办
这个错误通常是因为你在触发器函数里试图给一个 GENERATED ALWAYS 列（比如 identity 列或 computed 列）赋值，或者字段被定义为 NOT NULL 但标准化后变 NULL（比如 trim('') 得到 NULL，而字段不允许 NULL）。
排查重点：
- 检查触发器函数里是否对
NEW.id、NEW.created_at这类自动生成字段做了赋值 - 标准化函数如
trim()、regexp_replace()是否可能返回 NULL，导致违反NOT NULL约束 - 用
RAISE NOTICE '%', NEW.email;在触发器里临时加日志，确认实际传入值
真实场景中，最常被忽略的是：标准化逻辑依赖外部函数（比如调用 unaccent()），但数据库没装 unaccent 扩展，触发器一执行就报错中断，连带整个事务失败。
