一、为什么分区表的唯一约束必须包含所有分区列？ #

这其实是PostgreSQL声明式分区的设计逻辑决定的。咱们的分区表是把数据拆到不同子分区里存储的，每个子分区只对应特定的分区键值（比如你这里的category）。如果唯一约束（包括主键）不带分区列，数据库根本没法保证全局唯一性——举个例子，分区1里有个id=1，分区2里也可能出现id=1，数据库没法跨分区去校验重复，只能在单个分区里检查。

所以PostgreSQL要求唯一约束/主键必须包含分区列，这样每个子分区里的约束组合（比如id+category）就能保证全局范围内不会有重复值，毕竟同一个category分区里的id是唯一的，不同分区的category不一样，组合起来自然全局唯一。

二、自引用外键的解决方案（不用继承式分区） #

当你把主键改成(id, category)后，直接建指向id的外键肯定失败，因为外键要求引用的列必须有唯一约束。这里给你两个实用的方案：

方案1：让外键引用完整的主键组合 #

既然主键是(id, category)，那外键也得对应上。咱们可以加一个prev_category字段来存储前序事件的分类，然后创建包含两个字段的外键：

-- 先添加存储前序事件分类的字段
ALTER TABLE test2 ADD COLUMN prev_category integer;
-- 创建自引用外键
ALTER TABLE test2 ADD FOREIGN KEY (prev_event, prev_category) 
REFERENCES test2 (id, category) ON UPDATE CASCADE ON DELETE CASCADE;

这个方案最贴合PostgreSQL的分区设计规则，而且逻辑上也说得通——毕竟你的事件是按category分区的，前序事件大概率和当前事件同属一个分类；如果业务允许跨分类关联，这个字段也能明确存储对应的分类信息，避免歧义。

方案2：给id添加全局唯一约束（PostgreSQL 11+适用） #

如果你确实不想把category扯进外键里，那可以给id单独加一个全局唯一约束。不过要注意，PostgreSQL 11之后才支持给分区表加全局约束，而且需要先给每个子分区单独加id的唯一约束，再给主表加全局约束：

-- 假设你的子分区是test2_p0、test2_p1这类，先给每个子分区加id唯一约束
ALTER TABLE test2_p0 ADD CONSTRAINT test2_p0_id_unique UNIQUE (id);
ALTER TABLE test2_p1 ADD CONSTRAINT test2_p1_id_unique UNIQUE (id);
-- 给主表添加全局唯一约束
ALTER TABLE test2 ADD CONSTRAINT test2_id_global_unique UNIQUE (id);

做完这些，你就可以创建指向id的自引用外键了：

ALTER TABLE test2 ADD FOREIGN KEY (prev_event) 
REFERENCES test2 (id) ON UPDATE CASCADE ON DELETE CASCADE;

不过这个方案有个小麻烦：以后新增子分区时，都得手动给子分区加id的唯一约束，不然全局约束不会生效。另外，跨分区的唯一性检查可能会带来一些性能开销，业务量不大的话可以忽略。

总结 #

如果业务逻辑能适配，方案1是最优解，符合PostgreSQL分区表的设计初衷；如果必须单独用id做外键，方案2可以满足需求，但要记得维护子分区的约束。尽量别用继承式分区，声明式分区是PostgreSQL官方推荐的方案，功能更稳定也更易维护。

内容的提问来源于stack exchange，提问作者Kveri