> On Jan 7, 2026, at 13:59, Chao Li <[email protected]> wrote:
>
> Hi Hackers,
>
> This task is derived from [1], as “ALTER TABLE” is considered to exhibit
> “inconsistent” behaviors with partitioned tables. From the current
> documentation of “ALTER TABLE”, readers won’t get enough information to form
> a clear understanding of how these commands behave with partitioned tables,
> and this gap needs to be addressed.
>
> I have spent several days verifying sub-commands of “ALTER TABLE” one by one
> against partitioned tables from the following points:
>
> 1) Does an action on a parent partitioned table propagate to child partitions?
> 2) Does a value set on a parent partitioned table get automatically inherited
> by newly created partitions?
> 3) Does “ONLY partitioned-table” work as the documentation states (preventing
> propagation)?
> 4) Can an action be performed on a partitioned table and its children
> independently?
>
> From these four criteria, sub-commands fall into the following categories:
>
> C1 - Sub-commands that can only be used with a partitioned table; ONLY will
> lead to an error; using them with a child partition will lead to an error.
>
> * ADD COLUMN
> * DROP COLUMN
> * SET DATA TYPE
> * DROP EXPRESSION
> * ADD GENERATED AS IDENTITY
> * ADD GENERATED
> * DROP IDENTITY
> * SET sequence_option
> * RESTART
> * ALTER CONSTRAINT
>
>
> C2 - Sub-commands where using them with a partitioned table will
> automatically propagate to child partitions; ONLY prevents propagation; new
> partitions
> inherit the parent’s new setting; and child partitions can be set to
> different values than the parent.
>
> * SET DEFAULT
> * DROP DEFAULT
> * SET EXPRESSION AS
> * SET STORAGE
> * DROP CONSTRAINT
> * ENABLE/DISABLE [ REPLICA | ALWAYS] TRIGGER
>
> C3 - Slightly different from C2: new partitions will not inherit the parent’s
> setting.
>
> * SET STATISTICS
>
> C4 - Sub-commands that can be used on a partitioned table and child
> partitions independently; actions on the parent will not propagate to
> children; children
> can have different settings than the parent; new partitions will not inherit
> the parent’s setting; ONLY can be used but has no effect.
>
> * 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 - Slightly different from C4: new partitions will automatically inherit
> the parent’s setting.
>
> * SET COMPRESSION
>
> C6 - Slightly different from C2: ONLY cannot be used with a parent
> partitioned table, meaning the setting must be propagated to child partitions.
>
> * ADD table_constraint
>
> C7 - Sub-commands that cannot be used with a partitioned table, but can only
> be used with a leaf partition.
>
> * ADD table_constraint_with_index
> * ALTER CONSTRAINT … INHERIT / NO INHERIT
> * CLUSTER ON
> * SET WITHOUT CLUSTER
> * SET { LOGGED | UNLOGGED }
> * SET (storage_parameter)
>
>
> C8 - Slightly different from C1: child partitions can set different values
> than the parent.
>
> * VALIDATE CONSTRAINT
>
> C9 - Slightly different from C2: if the parent has a value, then new
> partitions will inherit that value; otherwise, they use the default from the
> GUC.
>
> * SET ACCESS METHOD
>
> C10 - Sub-commands used with a parent partitioned table will NOT propagate to
> child partitions; but new partitions will automatically inherit the parent’s
> setting; partitions can be set to different values than the parent; ONLY can
> be used but has no effect.
>
> * SET TABLESPACE
>
> C11 - Sub-commands used with a parent partitioned table won’t fail but do
> nothing; using them with a leaf partition works as with a normal table.
>
> * RESET (storage_parameter) # this appears questionable, because SET
> (storage_parameter) is not allowed on a partitioned table
>
> C12 - Sub-commands that don’t support partitioned tables; neither parent
> partitioned tables nor child partitions.
>
> * INHERIT parent_table
> * NO INHERIT parent_table
>
> C13 - Sub-commands that support only parent partitioned tables; ONLY can be
> used but has no effect; using them with a child partition will fail.
> * OF type
> * NOT OF
>
> C14 - Sub-commands that treat partitioned tables, either parent partitioned
> tables or child partitions, as normal tables, so no propagation occurs; ONLY
> can be used but has no effect.
>
> * RENAME
>
> C15 - Sub-commands that operate on partitioned tables.
>
> * ATTACH PARTITION
> * DETACH PARTITION
> * MERGE PARTITIONS
> * SPLIT PARTITION
>
> — End of categories —
>
> With these categories, we can clearly see where “inconsistencies” exist, and
> measure whether future changes mitigate these “inconsistencies” or make them
> worse. Some categories include only one or two sub-commands; maybe they can
> be adjusted to other categories so that some categories are eliminated and
> the overall “inconsistency” situation is improved.
>
> In this patch, I just want to add clarifications to the “ALTER TABLE”
> documentation, without changing any existing behaviors.
>
> This patch is pretty massive. Although I have done a self-review, I may still
> have missed things. I know this patch is a challenge for reviewers, so I’m
> open to any suggestions to make it easier to review and commit, such as
> splitting it in some way.
>
>
> [1]
> https://postgr.es/m/caeowx2nj71hy8r614hqr7vqhkbreo9aanpodpg0asqs74eo...@mail.gmail.com
>
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
> <v1-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch>
Added to CF: https://commitfest.postgresql.org/patch/6379/
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
