说个最常踩的坑：很多人写触发器做分表路由，上来就用AFTER INSERT，结果数据哗哗往主表写，子表一条都没进去。原因很简单——你得在数据落地之前，就决定它该去哪儿。
PostgreSQL里，BEFORE INSERT才是干这件事的正确时机。AFTER INSERT触发时，主表或者父表那边已经完成了写入尝试，要么成功了但数据进了错误的表，要么直接报错说找不到分区。特别是用声明式分区的时候，AFTER触发器根本改变不了插入目标，只能干瞪眼。继承表模型下也好不到哪去，AFTER触发后主表会多一次无效插入，还容易触发约束冲突，搞得一团糟。
BEFORE INSERT 才是路由的“黄金窗口”
只有BEFORE INSERT才能让你通过RETURN NULL或RETURN NEW来控制数据的流向。具体怎么选？
- 如果用继承模型（非声明式分区），
RETURN NULL表示取消主表插入，然后你在触发器里用EXECUTE手动写进子表 - 如果用声明式分区，
RETURN NEW就行了，但前提是目标分区必须已经存在，否则照样报错
很多人直接照着“日志表插入后创建子表”的示例代码抄，结果发现INSERT INTO parent_table总报no partition of relation "xxx" found for row。问题就出在触发器没在写入前拦截并重定向。所以，记住这个核心原则：路由必须发生在写入之前。
动态建表时，INHERITS 必须带空括号
这是继承表分表里最容易翻车的地方。很多示例代码漏掉了括号，结果建表语句直接报错。
CREATE TABLE log_2026 () INHERITS (log_parent); -- ✅ 正确
CREATE TABLE log_2026 INHERITS (log_parent); -- ❌ 报错：syntax error at or near "INHERITS"
括号的意思是“继承结构但不继承数据”，这是PostgreSQL的强制语法要求。漏掉后不仅建表失败，后续的INSERT也会因为子表缺失而中断。另外需要注意，建表语句中()不可省略，哪怕你不需要任何额外列。如果你想继承索引或约束，还得显式加上INCLUDING INDEXES或INCLUDING CONSTRAINTS。用format()拼接SQL时，记得注意单引号和双引号的嵌套，避免SQL注入风险。
分区键值解析必须严格校验
触发器里从NEW取分区字段后，不能直接拼进边界条件。举个例子，按月分区时，date_trunc('month', NEW.log_time)得到的是当月第一天，但如果你输入的是'2026-06-31'这种非法日期，PostgreSQL会静默转成'2026-07-01'，导致数据被写进下个月分区。
必须警惕的是，应用层来的数据往往没经过严格清洗。所以：
- 务必先校验输入的合法性，比如用
IS VALID或to_date()做一遍检查 - 时间范围边界建议统一用
date_trunc('month', ...)加interval '1 month'计算，避免手写字符串出错 - 哈希分表场景下，
hashint4(NEW.user_id) % 10要确认模数与实际子表数量一致，否则路由会溢出
并发插入时，CREATE TABLE IF NOT EXISTS 不够用
想象一个场景：几十个连接同时插入新月份的数据，都走到触发器里判断子表不存在，然后几乎同时执行CREATE TABLE。结果只有一个能成功，其他的都会报relation "xxx" already exists错误。这不是语法问题，而是典型的竞态条件。
解决方法不是加锁——PostgreSQL里无法在触发器里显式锁表——而是靠异常捕获加重试：
BEGIN EXECUTE format('CREATE TABLE %I (...) INHERITS (%I)', tbl_name, parent_name);EXCEPTION WHEN duplicate_table THEN -- 表已存在，继续插入END;
这里有几个要点：
- 必须捕获
duplicate_table异常，而不是笼统的OTHERS - 不要在异常块里再执行INSERT，让流程自然落到后续的
EXECUTE INSERT语句就行 - 高并发场景下，可以搭配
pg_advisory_lock对年份或月份做轻量级锁，但要控制好锁粒度和释放时机
说了这么多，其实触发器自动分表真正难的不是写几行PL/pgSQL代码，而是处理边界问题：非法输入、并发冲突、分区键变更，以及最容易被忽略的一点——子表DDL变更后如何同步到所有已有子表。比如给父表加个新字段，你得手动跑一遍ALTER TABLE ... ADD COLUMN到每个子表，触发器本身可不会帮你做这个善后工作。
