分区表是 PostgreSQL 的核心特性之一，但有一个问题即便资深用户也常会产生困惑：
在涉及分区时，ALTER TABLE 语句的具体执行逻辑是怎样的？
操作是否会同步至各分区？是否对新建分区生效？ONLY 关键字是否实现预期效果？为何部分命令可在主表执行却无法在分区执行，或反之？
当前 PostgreSQL 官方文档对单个 ALTER TABLE 子命令的说明较为完善，但很少系统性地解释它们在分区表场景下的整体行为。这导致真实行为往往只能通过反复试验才能被发现。
本文基于一次系统性验证，总结了 ALTER TABLE 在分区表上的行为规律，将零散规则归纳为一套统一的分类模型。
问题本质："不一致"并不等同于"未定义"
在 PostgreSQL 社区中，ALTER TABLE 在分区表上的行为常被描述为"不一致"。实际上，更深层的问题在于：
- 行为规则是存在的；
- 但规则分散在不同的代码路径、报错信息以及历史设计决策中；
- 且未以可预测结果的方式进行文档化说明。
在缺乏清晰认知模型的情况下，即便是简单问题也难以回答：
- 在父分区表上执行操作后，现有分区会发生什么？
- 后续新建的分区是否会继承相关设置？
ONLY是否能够阻止传播，还是会被直接忽略？- 能否为单个分区单独覆盖相关配置？
ALTER TABLE 子命令的验证方法
为厘清上述问题，本次研究针对所有 ALTER TABLE 子命令，在分区表场景下采用统一的问题框架开展测试验证。
四个评估维度
针对每个子命令，均围绕以下四个核心问题展开验证：
- 传播性（Propagation） 在父分区表上执行操作后，是否会传播到已有分区？
- 新分区继承性（Inheritance for new partitions） 后续新建的分区是否会继承父表的设置？
- ONLY 的影响（Effect of
ONLY）ONLY parent_table是否如文档所述，能够阻止操作传播？ - 独立性（Independence） 父表与各个分区是否可以拥有不同的配置值？
通过这四个维度，可以将模糊的"不一致"转化为明确、可验证的行为特征。
范围与版本说明
本分析基于 PostgreSQL 18 的开发版本行为（截至 2026 年初）。所有结论均在 PostgreSQL 18 上验证。部分细节在早期版本中可能存在差异，未来版本也可能随着分区机制的演进而发生变化。
分区表上 ALTER TABLE 的分类模型
基于上述评估维度，ALTER TABLE 的子命令可自然划分为 15 类，每一类对应一种明确的行为模式。
该分类仅作为执行逻辑的参考依据，而非价值判断。
C1 -- 仅作用于父表的结构性变更
此类特征如下：
- 仅可在分区表上使用；
- 在分区上执行会失败；
- 不支持
ONLY关键字。
包含的子命令：
ADD COLUMN（添加列）DROP COLUMN（删除列）SET DATA TYPE（修改数据类型）DROP EXPRESSION（删除表达式）ADD GENERATED AS IDENTITY（添加自增标识列）ADD GENERATED（添加生成列）SET sequence_option（设置序列参数）RESTART（重启序列）ALTER CONSTRAINT（修改约束）
此类命令用于定义分区表的整体结构，必须保持全局一致性。
C2 -- 可传播且可继承的变更
此类特征如下：
- 从父表传播至所有已有分区；
- 遵循
ONLY关键字的作用规则； - 新建分区会继承主表的相关配置；
- 支持为单个分区单独覆盖配置。
包含的子命令：
SET DEFAULT（设置默认值）DROP DEFAULT（删除默认值）SET EXPRESSION AS（设置表达式）SET STORAGE（设置存储参数）DROP CONSTRAINT（删除约束）ENABLE/DISABLE TRIGGER（启用 / 禁用触发器）
这是多数场景下对 ALTER TABLE 行为的直观预期。
C3 -- 可传播但不支持新分区继承
此类别仅包含一个子命令：
SET STATISTICS（设置统计信息参数）
执行逻辑与 C2 类基本一致，区别在于操作仅同步至现有分区，对后续新建分区不生效。若默认认为配置可自动继承，该特性易引发使用偏差。
C4 -- 父表与分区完全独立
此类特征如下：
- 不传播；
- 不继承；
- 允许父表与分区设置不同值；
- 支持
ONLY关键字，但无实际执行效果。
包含的子命令：
SET/RESET (attribute_option = value)（设置 / 重置属性参数）ENABLE/DISABLE [REPLICA | ALWAYS] RULE（启用 / 禁用复制 / 永久规则）ENABLE/DISABLE ROW LEVEL SECURITY（启用 / 禁用行级安全策略）NO FORCE / FORCE ROW LEVEL SECURITY（不强制 / 强制行级安全策略）OWNER TO（修改表属主）REPLICA IDENTITY（设置复制标识）SET SCHEMA（修改所属模式）
在行为上，父表与分区几乎等同于彼此独立的普通表。
C5 -- 独立设置，但新分区继承
此类别仅包含一个子命令：
SET COMPRESSION（设置压缩参数）
执行逻辑与 C4 基本一致，但新建分区会继承父表设置，已有分区不受影响。
C6 -- 强制传播类命令
此类别仅包含一个子命令：
ADD table_constraint（添加表级约束）
执行逻辑与 C2 类基本一致，但不允许使用 ONLY，系统会强制保证所有分区一致。
C7 -- 仅适用于叶子分区的命令
此类特征如下：
- 无法在分区表上使用；
- 只能在叶子分区上执行。
包含的子命令：
ADD table_constraint_with_index（添加带索引的表级约束）ALTER CONSTRAINT ... INHERIT / NO INHERIT（修改约束的继承 / 取消继承属性）CLUSTER ON（按指定索引聚簇）SET WITHOUT CLUSTER（取消聚簇）SET LOGGED / UNLOGGED（设置日志记录 / 无日志记录）SET (storage_parameter)（设置存储参数）
C8 -- 父表作用域，但允许分区覆盖
此类别仅包含一个子命令：
VALIDATE CONSTRAINT（验证约束）
执行逻辑与 C1 类基本一致，区别在于验证动作定义在父表层级，但各分区的验证状态可以不同。
C9 -- 条件继承型
此类别仅包含一个子命令：
SET ACCESS METHOD（设置访问方法）
执行逻辑与 C2 类基本一致，但新分区是否继承取决于父表是否显式设置；若未设置，则使用 GUC 默认值。
C10 -- 不传播，但新分区继承
此类别仅包含一个子命令：
SET TABLESPACE（设置表空间）
已有分区保持不变，新建分区继承父表设置。接受 ONLY，但无实际效果。
C11 -- 在父表上为空操作
此类别仅包含一个子命令：
RESET (storage_parameter)（重置存储参数）
此类命令在分区表上不会报错，但也不会产生任何实际变化。
C12 -- 不支持分区表的命令
包含的子命令：
INHERIT（继承表）NO INHERIT（取消继承表）
在概念上与声明式分区机制不兼容。
C13 -- 仅绑定父表元数据
包含的子命令：
OF type（绑定复合类型）NOT OF（取消复合类型绑定）
仅作用于分区表本身，在分区上执行会失败。接受 ONLY，但无实际效果。
C14 -- 按普通表处理
仅包含一个子命令：
RENAME（重命名）
无传播、无继承，也不存在分区相关的特殊行为。
C15 -- 分区管理类命令
包含的子命令：
ATTACH PARTITION（挂载分区）DETACH PARTITION（卸载分区）
用于操作分区结构本身，而非表属性。
结语
在 PostgreSQL 官方文档未对分区表的 ALTER TABLE 语句执行逻辑进行明确、体系化说明前，本分类模型可作为重要的参考依据。
若日常工作中频繁使用分区表，建议将该认知模型作为常用参考，在生产环境执行相关命令前，先确认其所属的执行类别，再开展操作，以降低不可预期风险。
原文链接：