PostgreSQL触发器中禁止执行CREATE TABLE或ATTACH PARTITION，因其元数据变更不支持事务内操作；应使用触发器仅做路由判断与错误拦截，配合pg_partman扩展通过后台任务实现动态分区管理。
触发器里不能直接执行 CREATE TABLE 或 ALTER TABLE ATTACH PARTITION
PostgreSQL 的 SQL 触发器函数（LANGUAGE plpgsql）在事务中运行，而分区管理类 DDL（如建分区表、挂载分区）默认是事务性不安全的——CREATE TABLE 在 12+ 版本虽支持事务内执行，但 ATTACH PARTITION 仍要求目标分区已存在且结构完全匹配主表，且不能在触发器中动态构造并立即挂载。直接写会报错：ERROR: cannot execute CREATE TABLE in a read-only transaction（尤其在 BEFORE INSERT 触发器中），或更常见的 ERROR: cannot attach partition in trigger。
根本原因：触发器执行时，事务尚未提交，而分区挂载操作需要对系统目录做持久化修改，PostgreSQL 明确禁止在触发器上下文中做这类元数据变更。
- 别试图在
BEFORE INSERT里EXECUTE format('CREATE TABLE ...')+ALTER TABLE ... ATTACH PARTITION -
AFTER INSERT也不行——触发器已退出，无法补救当前行插入失败的问题 - 真正可行的路径是：把分区创建逻辑外移到应用层或定时任务，触发器只做「路由判断」和「错误拦截」
用触发器实现「自动路由 + 拒绝未覆盖分区」
虽然不能动态建分区，但可以用触发器检查待插入数据是否落在已有分区范围内，若不匹配，就抛出明确错误，倒逼运维/应用提前创建对应分区。这是 PostgreSQL 官方推荐的稳健做法。
假设按 created_at 月度范围分区，主表为 events，已有 events_2024_01、events_2024_02：
CREATE OR REPLACE FUNCTION events_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF NEW.created_at < '2024-01-01'::DATE THEN
RAISE EXCEPTION 'no partition for % before 2024-01', NEW.created_at;
ELSIF NEW.created_at < '2024-02-01'::DATE THEN
INSERT INTO events_2024_01 VALUES (NEW.*);
ELSIF NEW.created_at < '2024-03-01'::DATE THEN
INSERT INTO events_2024_02 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'no partition for % (expected < 2024-03-01)', NEW.created_at;
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
- 必须用
BEFORE INSERT ON events触发器，且主表设为WITHOUT OIDS和INHERITS已废弃，应使用原生声明式分区 - 所有
INSERT INTO必须显式指向子分区，不能写INSERT INTO events（否则递归触发） - 返回
NULL阻止主表插入；返回NEW会导致主表也插一份（重复）
配合 pg_partman 实现真正的「动态分区生成」
硬靠触发器做不到全自动分区创建，但 pg_partman 扩展能接管这事——它通过后台定期作业（run_maintenance()）检查时间/序列范围，自动建新分区、删旧分区。触发器只需专注路由，无需越界。
安装后，初始化一个按月分区的配置：
SELECT partman.create_parent( p_parent_table := 'public.events', p_control := 'created_at', p_type := 'native', p_interval := 'monthly', p_premake := 2, p_automatic_maintenance := 'on' );
-
p_premake := 2表示预先建好当前月+下两个月的分区 - 调用
partman.run_maintenance()（可设为 cron 或 pg_cron job）自动补全 - 此时你的触发器只需做最简路由（甚至可删掉——原生分区已支持
INSERT自动路由到匹配子表） - 注意：
pg_partman的分区名格式固定（如events_p2024_03），别在触发器里手写硬编码
容易被忽略的权限与维护陷阱
即使用了 pg_partman，以下三点常导致分区“看似自动”实则中断：
-
pg_partman运行用户必须对父表有CREATE权限（才能建子表），且需在对应 schema 有USAGE+CREATE - 如果手动删过子分区但没调用
partman.drop_partition()，元数据残留会导致run_maintenance()拒绝建新分区 - 时间字段必须带时区或统一转成
DATE，否则'2024-03-01'和'2024-03-01 00:00:00+08'路由结果可能不一致 - 分区键表达式（如
date_trunc('month', created_at)）必须和pg_partman配置的p_control完全一致，否则路由失效
分区不是设完就一劳永逸的事——它把「建表时机」从插入瞬间转移到了维护窗口，而那个窗口是否可靠，取决于你对 pg_partman 权限、调度、状态检查的把控程度。
