分区表是 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 语句执行逻辑进行明确、体系化说明前，本分类模型可作为重要的参考依据。

若日常工作中频繁使用分区表，建议将该认知模型作为常用参考，在生产环境执行相关命令前，先确认其所属的执行类别，再开展操作，以降低不可预期风险。