docs: clarify ALTER TABLE behavior on partitioned tables

On Jan 7, 2026, at 13:59, Chao Li <li.evan.chao@gmail.com> 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] /messages/by-id/CAEoWx2nJ71hy8R614HQr7vQhkBReO9AANPODPg0aSQs74eOdLQ@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/

On Wed, Jan 7, 2026 at 1:29 AM Chao Li <li.evan.chao@gmail.com> wrote:

[1]

/messages/by-id/CAEoWx2nJ71hy8R614HQr7vQhkBReO9AANPODPg0aSQs74eOdLQ@mail.gmail.com

<v1-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch>

Added to CF: https://commitfest.postgresql.org/patch/6379/

Fairly easy to review in its current form.

I've included my changes as a patch over your version 1.

The main points of interest:

Saying that "ONLY" is a no-op when the observed behavior is that only
the mentioned tables are affected seems wrong. I've removed those
instances.

I tried to keep the "and 'is implicitly <actioned>" verbiage consistent
throughout. "Implicitly present" just seems off regardless of consistency.

"new partitions created in the future" - this is wordy given that "new"
implies "created in the future". Went with a simple "Newly created
partitions".

I did mentally note at the end of this review session that quite a bit of
text is spent saying how "create table" works in this "alter table"
reference. I didn't try to address it though.

You were using "can be applied independently" when in fact one "must"
specify all desired tables to be acted upon in those sub-commands. And, in
that case in particular, if ONLY is accepted it would just do what the
command already does. I removed the mention of ONLY in these "must" cases.

The majority of additions you made and existing mentions of "individual
partitions" do not include the clarification of "(leaf)". I removed those
that did - it seems like an unnecessary clarification.

If one has dropped a constraint from a partitioned table there would be no
reason to expect that future newly created partitions might somehow have
it. I removed the wording that stated that this was the case.

It didn't seem necessary to point out that the obsolete backward compatible
syntax for OIDS doesn't apply to partition-related tables.

Overall it looks good. The mentions of "newly created ... do [not]
inherit" is my only place of doubt. I'd be inclined to remove them all,
and if they are not covered elsewhere, introduce a section to cover them in
the DDL chapter.

David J.

On Jan 8, 2026, at 06:17, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Wed, Jan 7, 2026 at 1:29 AM Chao Li <li.evan.chao@gmail.com> wrote:

[1] /messages/by-id/CAEoWx2nJ71hy8R614HQr7vQhkBReO9AANPODPg0aSQs74eOdLQ@mail.gmail.com

<v1-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch>

Added to CF: https://commitfest.postgresql.org/patch/6379/

Fairly easy to review in its current form.

I've included my changes as a patch over your version 1.

Hi David,

Thank you very much for the careful review. Your edits make the documentation clearer and more fluent, and I agree with most of your suggestions.

The main points of interest:

Saying that "ONLY" is a no-op when the observed behavior is that only the mentioned tables are affected seems wrong. I've removed those instances.

Maybe the original phrasing “has no effect” wasn’t clear for what I meant. What I was trying to express is that ONLY is intended to control whether an action propagates to child tables: with ONLY it should not propagate, and without ONLY it should.

For these particular sub-commands, however, the observed behavior is that they behave the same with or without ONLY. From a documentation perspective, stating that explicitly could help avoid user confusion.

Separately, I do have a plan to tighten this behavior in the future: for these commands, specifying ONLY would raise an error instead. If such a change is merged later, the documentation note could naturally be removed at that point.

So I’d like to keep the statement for now, but I’m very happy to adjust the wording if you have a clearer phrasing to suggest.

I saw you removed such “has no effect” from “DISABLE/ENABLE RULE”, “DISABLE/ENABLE ROW LEVEL SECURITY”, “NO FORCE ROW LEVEL SECURITY”, and , and retained some.

I tried to keep the "and 'is implicitly <actioned>" verbiage consistent throughout. "Implicitly present" just seems off regardless of consistency.

Agreed.

"new partitions created in the future" - this is wordy given that "new" implies "created in the future". Went with a simple "Newly created partitions".

Agreed.

I did mentally note at the end of this review session that quite a bit of text is spent saying how "create table" works in this "alter table" reference. I didn't try to address it though.

The current documentation already mentions the behavior of newly created partitions in some sections. For example:

SET ACCESS METHOD
```
When applied to a partitioned table, there is no data to rewrite, but partitions created afterwards will default to the given access method unless overridden by a USING clause.
```

SET TABLESPACE
```
When applied to a partitioned table, nothing is moved, but any partitions created afterwards with CREATE TABLE PARTITION OF will use that tablespace, unless overridden by a TABLESPACE clause.
```

I think this helps users quickly understand the important implications for future partitions.

You were using "can be applied independently" when in fact one "must" specify all desired tables to be acted upon in those sub-commands. And, in that case in particular, if ONLY is accepted it would just do what the command already does. I removed the mention of ONLY in these "must" cases.

I saw you changed “independently” to “separately”, I agree with that part. For ONLY, as explained above, I want to retain the statement.

The majority of additions you made and existing mentions of "individual partitions" do not include the clarification of "(leaf)". I removed those that did - it seems like an unnecessary clarification.

Agreed.

If one has dropped a constraint from a partitioned table there would be no reason to expect that future newly created partitions might somehow have it. I removed the wording that stated that this was the case.

That’s true. Agreed.

It didn't seem necessary to point out that the obsolete backward compatible syntax for OIDS doesn't apply to partition-related tables.

Agreed.

Overall it looks good. The mentions of "newly created ... do [not] inherit" is my only place of doubt. I'd be inclined to remove them all, and if they are not covered elsewhere, introduce a section to cover them in the DDL chapter.

As mentioned above, the current documentation already describes the behavior of newly created partitions in some sections, so I would prefer to retain these mentions for now. That said, I’m happy to wait for more opinions.

Before I integrate your edits and prepare v3, I’d appreciate hearing your thoughts on the points about ONLY and “newly created”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Fri, Jan 9, 2026 at 1:11 AM Chao Li <li.evan.chao@gmail.com> wrote:

The main points of interest:

Saying that "ONLY" is a no-op when the observed behavior is that only

the mentioned tables are affected seems wrong. I've removed those
instances.

Maybe the original phrasing “has no effect” wasn’t clear for what I meant.
What I was trying to express is that ONLY is intended to control whether an
action propagates to child tables: with ONLY it should not propagate, and
without ONLY it should.

For these particular sub-commands, however, the observed behavior is that
they behave the same with or without ONLY. From a documentation
perspective, stating that explicitly could help avoid user confusion.

Separately, I do have a plan to tighten this behavior in the future: for
these commands, specifying ONLY would raise an error instead. If such a
change is merged later, the documentation note could naturally be removed
at that point.

So I’d like to keep the statement for now, but I’m very happy to adjust
the wording if you have a clearer phrasing to suggest.

I've removed some I missed and tweaked others. I'm OK with leaving mention
of ONLY in these sections but what happens is that ONLY becomes implicitly
added to the command, which is what I'd rather communicate. The remaining
wording is a bit redundant now but flows nicely.

Before I integrate your edits and prepare v3, I’d appreciate hearing your
thoughts on the points about ONLY and “newly created”.

As I continue to think about the "newly created" material the more I
believe it is misplaced. That there is existing wording to that effect
doesn't change my conclusion. I would add no additional text here even if
you don't want to remove the existing mentions at this point. But I think
the scope of this patch should be increased to fix this misplacement as
well. Since moving content - refactoring - is what is happening here. In
the attached 0003 I've removed the paragraphs that this patch now makes
redundant within the alter table documentation. I wouldn't mind if they
got moved to somewhere in Chapter 5.12 (Table Partitioning) and not just
erased, along with ensuring that 5.12 includes how table creation
definition inheritance works and removing those mentions from the alter
table docs as well.

I'm not sure whether I'd fully remove all that content since some of it
does pertain just to table inheritance. That feature seems like something
best related to notes and not brought into the main flow like you are doing
with partitioned tables.

David J.

On Jan 10, 2026, at 00:12, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Fri, Jan 9, 2026 at 1:11 AM Chao Li <li.evan.chao@gmail.com> wrote:

The main points of interest:

Saying that "ONLY" is a no-op when the observed behavior is that only the mentioned tables are affected seems wrong. I've removed those instances.

Maybe the original phrasing “has no effect” wasn’t clear for what I meant. What I was trying to express is that ONLY is intended to control whether an action propagates to child tables: with ONLY it should not propagate, and without ONLY it should.

For these particular sub-commands, however, the observed behavior is that they behave the same with or without ONLY. From a documentation perspective, stating that explicitly could help avoid user confusion.

Separately, I do have a plan to tighten this behavior in the future: for these commands, specifying ONLY would raise an error instead. If such a change is merged later, the documentation note could naturally be removed at that point.

So I’d like to keep the statement for now, but I’m very happy to adjust the wording if you have a clearer phrasing to suggest.

I've removed some I missed and tweaked others. I'm OK with leaving mention of ONLY in these sections but what happens is that ONLY becomes implicitly added to the command, which is what I'd rather communicate. The remaining wording is a bit redundant now but flows nicely.

Changing the phrase “has no effect” to “implicitly” looks good to me. ONLY is implicit on the following sub-commands:

* 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
* SET COMPRESSION
* SET TABLESPACE
* OF type
* NOT OF
* RENAME

I saw you removed “ONLY” statement from some of them and changing “has no effect” to “implicit” on rests. So, I just want to confirm if you intentionally removed those or just missed changing them?

Before I integrate your edits and prepare v3, I’d appreciate hearing your thoughts on the points about ONLY and “newly created”.

As I continue to think about the "newly created" material the more I believe it is misplaced. That there is existing wording to that effect doesn't change my conclusion. I would add no additional text here even if you don't want to remove the existing mentions at this point. But I think the scope of this patch should be increased to fix this misplacement as well. Since moving content - refactoring - is what is happening here. In the attached 0003 I've removed the paragraphs that this patch now makes redundant within the alter table documentation. I wouldn't mind if they got moved to somewhere in Chapter 5.12 (Table Partitioning) and not just erased, along with ensuring that 5.12 includes how table creation definition inheritance works and removing those mentions from the alter table docs as well.

A new partition automatically inheriting the parent’s setting is an expected behavior, and most of sub-commands meet the expectation. So I’m fine to remove the “newly created” material from these “good" sub-commands.

Only a few sub-commands break the expectation, they are:

* SET STATISTICS
* 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

The current behavior (not inherit) is questionable, we will need separate discussions for each of them to clarify if that’s intended or “bugs”. So, how about only retain the “newly created” material for these sub-commands and remove from the rests? In this case, I don’t think we need to update 5.12.

What I am thinking is that, we will eventually remove the “newly created” material from these sub-commands, because next step we are going to fix the behavior on them one by one. Maybe some of them are designed to not “inherit the parent’s setting”, then we can add a paragraph/section to 5.12 to describe that.

I'm not sure whether I'd fully remove all that content since some of it does pertain just to table inheritance. That feature seems like something best related to notes and not brought into the main flow like you are doing with partitioned tables.

David J.

<v2-0001-docs-Clarify-ALTER-TABLE-v1.patch><v2-0003-docs-ONLY-tweaks-and-bulk-note-removal.patch><v2-0002-docs-Clarify-ALTER-TABLE-v1-edits.patch>

--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Sunday, January 11, 2026, Chao Li <li.evan.chao@gmail.com> wrote:

The current behavior (not inherit) is questionable, we will need separate
discussions for each of them to clarify if that’s intended or “bugs”. So,
how about only retain the “newly created” material for these sub-commands
and remove from the rests? In this case, I don’t think we need to update
5.12.

What I am thinking is that, we will eventually remove the “newly created”
material from these sub-commands, because next step we are going to fix the
behavior on them one by one. Maybe some of them are designed to not
“inherit the parent’s setting”, then we can add a paragraph/section to 5.12
to describe that.

I’m against having material in the alter table command that doesn’t
describe the effects of executing alter table. I’d consider possibly
pointing out if the cascade behavior of alter table doesn’t match up with
the inherit behavior of create table. There doesn’t seem to be any such
discrepancies though. I also have my doubts that any of this behavior is
going to change. Better to behave as if it won’t.

David J.

On Jan 12, 2026, at 12:04, David G. Johnston <david.g.johnston@gmail.com> wrote:

I also have my doubts that any of this behavior is going to change. Better to behave as if it won’t.

Please see [1]/messages/by-id/59FB38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com, people wanted to change the behavior from long time back. From the previous discussions, there were no objections on the behavior change. However, the blocker was about how to keep “consistent” behaviors across all sub-commands. That’s why I created this patch to clarify the current behaviors.

[1]: /messages/by-id/59FB38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Sun, Jan 11, 2026 at 10:52 PM Chao Li <li.evan.chao@gmail.com> wrote:

[1] /messages/by-id/59FB38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com
If we stop here, these inconsistencies will remain indefinitely, which I
believe nobody really wants. With that in mind, I’d like to suggest a
two-phase approach.

Phase 1: Document current behavior and set expectations

* Identify all ALTER TABLE actions involved in these inconsistencies.
* Update the ALTER TABLE and CREATE TABLE documentation to clearly
describe the current behavior for partitioned tables, and (where
appropriate) the intended or ideal behavior.
* Explicitly document the meaning of ONLY for partitioned tables, and note
that some actions may behave differently, with details described in each
action’s section.

I agree, we should modify alter to note the cascade and/or non-cascade
scenarios and modify create to note the things that are (not) inherited.
I'm fine with the "newly created" stuff being put into create table instead
of touching 5.12.

We should not be documenting "ideal behavior" - only actual behavior.

We should indeed document that ONLY, if added to an alter command that
would cascade to partitions, prevents that cascading. If added to a
command that wouldn't cascade anyway it is usually accepted as just
specifying the default behavior. There is no way to indicate explicitly
that one wishes to cascade.

I still have my doubts whether changing long-standing behavior is going to
happen. But that is also fairly immaterial since best practice is to
proceed without even trying to predict the future and instead just deal
with what is in front of us right now.

David J.

On Jan 13, 2026, at 08:20, David G. Johnston <david.g.johnston@gmail.com>
wrote:

On Sun, Jan 11, 2026 at 10:52 PM Chao Li <li.evan.chao@gmail.com> wrote:

[1]: /messages/by-id/59FB38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com If we stop here, these inconsistencies will remain indefinitely, which I believe nobody really wants. With that in mind, I’d like to suggest a two-phase approach.
If we stop here, these inconsistencies will remain indefinitely, which I
believe nobody really wants. With that in mind, I’d like to suggest a
two-phase approach.

Phase 1: Document current behavior and set expectations

* Identify all ALTER TABLE actions involved in these inconsistencies.
* Update the ALTER TABLE and CREATE TABLE documentation to clearly describe
the current behavior for partitioned tables, and (where appropriate) the
intended or ideal behavior.
* Explicitly document the meaning of ONLY for partitioned tables, and note
that some actions may behave differently, with details described in each
action’s section.

I agree, we should modify alter to note the cascade and/or non-cascade
scenarios and modify create to note the things that are (not) inherited.
I'm fine with the "newly created" stuff being put into create table instead
of touching 5.12.

I have removed all “newly created” from "alter table” doc, and added a
paragraph in “create table” doc for those settings a new partition doesn’t
inherit from the parent.

We should not be documenting "ideal behavior" - only actual behavior.

Absolutely.

We should indeed document that ONLY, if added to an alter command that
would cascade to partitions, prevents that cascading. If added to a
command that wouldn't cascade anyway it is usually accepted as just
specifying the default behavior. There is no way to indicate explicitly
that one wishes to cascade.

I went through all sub-commands and added ONLY back.

I still have my doubts whether changing long-standing behavior is going to
happen. But that is also fairly immaterial since best practice is to
proceed without even trying to predict the future and instead just deal
with what is in front of us right now.

Let’s leave the discussion to separate threads.

Hi David, I have squashed all commits into one. As you have contributed a
lot of work, I marked you as an author as well as a reviewer. Thanks a lot.
Please take a look at v3 again.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_table.sgml
index 8577e2cdcdd..188f8f3e04b 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -746,11 +746,8 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When this command is applied to a partitioned table, the states of
-      corresponding clone triggers in existing partitions are updated too,
-      unless <literal>ONLY</literal> is specified. Triggers in partitions
-      created afterwards inherit the trigger state from the partitioned
-      table, while individual partitions may configure trigger states
-      independently.
+      corresponding clone triggers are updated too, unless
<literal>ONLY</literal>
+      is specified.
      </para>
      <para>
       This command acquires a <literal>SHARE ROW EXCLUSIVE</literal> lock.

"existing partitions" is implied here; and the rest is material for create
table or implied by the optional ONLY (as we rely upon elsewhere):
<para>
For partitioned tables, this action applies to the partitioned table
and all of its partitions unless <literal>ONLY</literal> is specified.
</para>

@@ -882,14 +879,11 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
       See <xref linkend="tableam"/> for more information.
      </para>
      <para>
-      When applied to a partitioned table, there is no data to rewrite.
-      Partitions created afterwards will use the access method specified
-      on the partitioned table, if any, unless overridden by a
-      <literal>USING</literal> clause; otherwise they default to
-      <varname>default_table_access_method</varname>. Specifying
-      <literal>DEFAULT</literal> removes a previously set access method,
-      causing future partitions to use
-      <varname>default_table_access_method</varname>.
+      When applied to a partitioned table, there is no data to rewrite,
+      only the default for newly created partitions is changed.
+      Specifying <literal>DEFAULT</literal> removes a previously set
access method,
+      causing future partitions to use
<varname>default_table_access_method</varname>.
+      Individual partitions are affected just like any other regular table.
      </para>
     </listitem>
    </varlistentry>

The wording of 'changes the default' adequately condenses the existing
wording. I'm 50/50 on removing mention of default_table_access_method.

@@ -902,10 +896,8 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
       moves the data file(s) associated with the table to the new
tablespace.
       Indexes on the table, if any, are not moved; but they can be moved
       separately with additional <literal>SET TABLESPACE</literal>
commands.
-      When applied to a partitioned table, no data is moved. Existing
-      partitions are not affected, but partitions created afterwards with
-      <command>CREATE TABLE PARTITION OF</command> will use the specified
-      tablespace unless overridden by a <literal>TABLESPACE</literal>
clause.
+      When applied to a partitioned table, no data is moved, only the
default
+      for newly created partitions is changed.
      </para>
      <para>
       All tables in the current database in a tablespace can be moved by
using

Again, 'default' can carry a lot of implied meaning here.

@@ -984,7 +976,7 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When applied to a partitioned table, this form is accepted but has no
-      effect.  It can be used on individual partitions, where it
+      practical effect.  It can be used on individual partitions, where it
       behaves as for a regular table.
      </para>
     </listitem>

I don't quite like saying 'no effect' since the command does function; and
explaining why it is useless seemed a bit much, so just added the word
'practical' and left it to the reader to infer that the lack of storage and
inheritance makes any such property on the partitioned table itself useless.

diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM

      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.

diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM

      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.

Dislike the word "setting" here as it clashes with GUC. Was going to use
"attribute" but its used for column. Settled on "property".
"Definition-level" seems redundant, consider removing it.

Attached patch as text.

David J.

On Jan 18, 2026, at 00:15, David G. Johnston <david.g.johnston@gmail.com>
wrote:

diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_table.sgml
index 8577e2cdcdd..188f8f3e04b 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -746,11 +746,8 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When this command is applied to a partitioned table, the states of
-      corresponding clone triggers in existing partitions are updated too,
-      unless <literal>ONLY</literal> is specified. Triggers in partitions
-      created afterwards inherit the trigger state from the partitioned
-      table, while individual partitions may configure trigger states
-      independently.
+      corresponding clone triggers are updated too, unless
<literal>ONLY</literal>
+      is specified.
      </para>
      <para>
       This command acquires a <literal>SHARE ROW EXCLUSIVE</literal> lock.

"existing partitions" is implied here; and the rest is material for create
table or implied by the optional ONLY (as we rely upon elsewhere):
<para>
For partitioned tables, this action applies to the partitioned table
and all of its partitions unless <literal>ONLY</literal> is specified.
</para>

Agreed.

@@ -882,14 +879,11 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
       See <xref linkend="tableam"/> for more information.
      </para>
      <para>
-      When applied to a partitioned table, there is no data to rewrite.
-      Partitions created afterwards will use the access method specified
-      on the partitioned table, if any, unless overridden by a
-      <literal>USING</literal> clause; otherwise they default to
-      <varname>default_table_access_method</varname>. Specifying
-      <literal>DEFAULT</literal> removes a previously set access method,
-      causing future partitions to use
-      <varname>default_table_access_method</varname>.
+      When applied to a partitioned table, there is no data to rewrite,
+      only the default for newly created partitions is changed.
+      Specifying <literal>DEFAULT</literal> removes a previously set
access method,
+      causing future partitions to use
<varname>default_table_access_method</varname>.
+      Individual partitions are affected just like any other regular table.
      </para>
     </listitem>
    </varlistentry>

The wording of 'changes the default' adequately condenses the existing
wording. I'm 50/50 on removing mention of default_table_access_method.

Updated to your version.

@@ -902,10 +896,8 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
       moves the data file(s) associated with the table to the new
tablespace.
       Indexes on the table, if any, are not moved; but they can be moved
       separately with additional <literal>SET TABLESPACE</literal>
commands.
-      When applied to a partitioned table, no data is moved. Existing
-      partitions are not affected, but partitions created afterwards with
-      <command>CREATE TABLE PARTITION OF</command> will use the specified
-      tablespace unless overridden by a <literal>TABLESPACE</literal>
clause.
+      When applied to a partitioned table, no data is moved, only the
default
+      for newly created partitions is changed.
      </para>
      <para>
       All tables in the current database in a tablespace can be moved by
using

Again, 'default' can carry a lot of implied meaning here.

Agreed.

@@ -984,7 +976,7 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM
      </para>
      <para>
       When applied to a partitioned table, this form is accepted but has no
-      effect.  It can be used on individual partitions, where it
+      practical effect.  It can be used on individual partitions, where it
       behaves as for a regular table.
      </para>
     </listitem>

I don't quite like saying 'no effect' since the command does function; and
explaining why it is useless seemed a bit much, so just added the word
'practical' and left it to the reader to infer that the lack of storage and
inheritance makes any such property on the partitioned table itself useless.

Agreed.

diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM

      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.

diff --git a/doc/src/sgml/ref/create_table.sgml
b/doc/src/sgml/ref/create_table.sgml
index 780e4f0799f..835f609e2a6 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -635,9 +635,9 @@ WITH ( MODULUS <replaceable
class="parameter">numeric_literal</replaceable>, REM

      <para>
       When a new partition is created, it generally inherits the current
-      definition-level settings of the parent partitioned table. However,
+      definition-level properties of the parent partitioned table. However,
       some table properties are not inherited automatically. In particular,
-      settings related to ownership, schema, replica identity, row-level
+      properties related to ownership, schema, replica identity, row-level
       security configuration, per-attribute statistics targets, and
       per-attribute options are not inherited unless explicitly specified
       for the partition.

Dislike the word "setting" here as it clashes with GUC. Was going to use
"attribute" but its used for column. Settled on "property".
"Definition-level" seems redundant, consider removing it.

Updated.

Hi David,

Thanks again for your review. I have integrated all your edits to v4. Once
you consider the changes are okay, can you please mark the CF entry [1]https://commitfest.postgresql.org/patch/6379/ as
Ready for Committer?

[1]: https://commitfest.postgresql.org/patch/6379/

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Mon, Jan 19, 2026 at 1:20 AM Chao Li <li.evan.chao@gmail.com> wrote:

Thanks again for your review. I have integrated all your edits to v4. Once
you consider the changes are okay, can you please mark the CF entry [1] as
Ready for Committer?

v5 Attached with a delta.

There exists described behaviors in the notes that are being removed that
need to be retained; pertaining to inheritance setups. I put a note in
place of the removals pointing out that when inheritance is being used for
partitioning the rules for partitioned tables apply (implied 'unless
otherwise noted') and that local/independent objects can always be
addressed normally. I then incorporated the notes into the appropriate
sub-command sections. Please give it a sanity check since I'm still
getting my head around all this.

David J.

On Jan 21, 2026, at 09:09, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Mon, Jan 19, 2026 at 1:20 AM Chao Li <li.evan.chao@gmail.com> wrote:

Thanks again for your review. I have integrated all your edits to v4. Once you consider the changes are okay, can you please mark the CF entry [1] as Ready for Committer?

v5 Attached with a delta.

There exists described behaviors in the notes that are being removed that need to be retained; pertaining to inheritance setups. I put a note in place of the removals pointing out that when inheritance is being used for partitioning the rules for partitioned tables apply (implied 'unless otherwise noted') and that local/independent objects can always be addressed normally. I then incorporated the notes into the appropriate sub-command sections. Please give it a sanity check since I'm still getting my head around all this.

David J.

<v5-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch><v5-0002-delta.patch>

Hi David,

Thanks for your continuous review. I just checked the delta:

1 - DROP COLUMN
```
+     <para>
+      For inheritance setups, a descendant column is removed only if both: this
+      is the only parent defining the column, and the column was never independently
+      defined.
+     </para>
```

The meaning is basically correct. I dislike the statement of “only if both:”, can we rephrase like:
```
For inheritance setups, a descendant column is removed only if both of the
following are true: this is the only parent defining the column, and the column
was never independently defined in the descendant.
```

What do you think?

2 - ADD table_constain
```
+     <para>
+      For inheritance setups, the constraint is not added to child tables
+      unless it is a <literal>CHECK</literal> constraint with the (implicit)
+      <literal>INHERIT</literal> property.
+     </para>
```

The meaning is also correct. I want a slight tweak like:
```
For inheritance setups, the constraint is not added to child tables unless it is
a CHECK constraint that is inheritable (that is, not declared NO INHERIT).
```

What do you think?

3 - VALIDATE CONSTRAINT
```
-      independently of the partitioned table.
+      independently of the partitioned table, so long as the partitioned
+      table itself is not yet validated.
```

Agreed.

4 - DISABLE/ENABLE TRIGGER
```
+     <para>
+      For inheritance setups <literal>ONLY</literal> is implied, though it may
+      be specified.
+     </para>
```

Agreed.

5 - RENAME
```
-      For partitioned tables, this form behaves the same as for regular
-      tables. Renaming a partitioned table, column, or constraint does not
-      propagate to partitions.
+      When applied to a partitioned table, partition columns constraints
+      are implicitly renamed and specifying <literal>ONLY</literal> is not allowed.
+     </para>
+     <para>
+      For inheritance setups, index-based constraints are always considered
+      independent.  Dependent columns and constraints are implicitly renamed
+      and specifying <literal>ONLY</literal> is not allowed.
```

Here “specifying ONLY is not allowed” is wrong. ONLY can be specified, but has no effect. So I think we can use the statement you put to ENABLE/DISABLE TRIGGER: “ONLY is implied, though it may be specified”.

6 - Notes
```
+   <para>
+    For inheritance setups, the behavior described for partitioned tables applies
+    only to the dependent column(s) on the descendant table(s).  It is always
+    allowed to target a descendant table with column altering commands on independent
+    columns.
+   </para>
```

Agreed.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Tuesday, January 20, 2026, Chao Li <li.evan.chao@gmail.com> wrote:

On Jan 21, 2026, at 09:09, David G. Johnston <david.g.johnston@gmail.com>

wrote:

On Mon, Jan 19, 2026 at 1:20 AM Chao Li <li.evan.chao@gmail.com> wrote:

Thanks again for your review. I have integrated all your edits to v4.

Once you consider the changes are okay, can you please mark the CF entry
[1] as Ready for Committer?

v5 Attached with a delta.

There exists described behaviors in the notes that are being removed

that need to be retained; pertaining to inheritance setups. I put a note
in place of the removals pointing out that when inheritance is being used
for partitioning the rules for partitioned tables apply (implied 'unless
otherwise noted') and that local/independent objects can always be
addressed normally. I then incorporated the notes into the appropriate
sub-command sections. Please give it a sanity check since I'm still
getting my head around all this.

David J.

<v5-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-

.patch><v5-0002-delta.patch>

Hi David,

Thanks for your continuous review. I just checked the delta:

The tweaks all look good.

David J.

On Jan 21, 2026, at 11:08, David G. Johnston <david.g.johnston@gmail.com>
wrote:

On Tuesday, January 20, 2026, Chao Li <li.evan.chao@gmail.com> wrote:

On Jan 21, 2026, at 09:09, David G. Johnston <david.g.johnston@gmail.com>

wrote:

On Mon, Jan 19, 2026 at 1:20 AM Chao Li <li.evan.chao@gmail.com> wrote:

Thanks again for your review. I have integrated all your edits to v4.

Once you consider the changes are okay, can you please mark the CF entry
[1]: as Ready for Committer?

v5 Attached with a delta.

There exists described behaviors in the notes that are being removed that

need to be retained; pertaining to inheritance setups. I put a note in
place of the removals pointing out that when inheritance is being used for
partitioning the rules for partitioned tables apply (implied 'unless
otherwise noted') and that local/independent objects can always be
addressed normally. I then incorporated the notes into the appropriate
sub-command sections. Please give it a sanity check since I'm still
getting my head around all this.

David J.

<v5-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch><v5-0002-delta.patch>

Hi David,

Thanks for your continuous review. I just checked the delta:

The tweaks all look good.

David J.

Cool! Your edits and my tweaks are integrated into v6.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Hello

Really good changes!

+ When applied to a partitioned table, the constraint is altered on the
+ partitioned table definition is implicitly applied to all partitions.

an "and" is missing here (definition and is)

+      When applied to a partitioned table, partition columns constraints
+      are implicitly renamed and specifying <literal>ONLY</literal>
is not allowed.
+     </para>

"partition columns constraints" - that seems like a strange/unclear
wording to me. maybe ", the partition's column constraints are ... " ?

+     <para>
+      When applied to a partitioned table <literal>ONLY</literal> is implicit,
+      these forms must be applied separately to the partitioned table and/or to
+      individual partitions.
+     </para>

"When applied to a partitioned table, <literal>ONLY</literal> is
implicit and ..." (at multiple places, this is an example)

- <para>
- A recursive <literal>DROP COLUMN</literal> operation will remove a
- descendant table's column only if the descendant does not inherit
- that column from any other parents and never had an independent
- definition of the column. A nonrecursive <literal>DROP
- COLUMN</literal> (i.e., <command>ALTER TABLE ONLY ... DROP
- COLUMN</command>) never removes any descendant columns, but
- instead marks them as independently defined rather than inherited.
- A nonrecursive <literal>DROP COLUMN</literal> command will fail for a
- partitioned table, because all partitions of a table must have the same
- columns as the partitioning root.
- </para>

"A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN)
never removes any descendant columns, but instead marks them as
independently defined rather than inherited."

This part is now undocumented, it was only mentioned in this paragraph.

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.

The documentation of this group is inconsistent.

DROP CONSTRAINT mentions that individual partitions can be dropped separately:

+      When applied to a partitioned table, the constraint is dropped from
+      all existing partitions unless <literal>ONLY</literal> is specified.
+      Individual partitions may drop constraints independently of the
+      partitioned table.

But most of the sub commands in the C2 group leave the last sentence
out, and also the C7 (ADD table_constraint)

Also, isn't DROP CONSTRAINT on a partition limited to constraints
defined on that partition? So it would be better to say "may drop
constraints defined directly on that individual partition
independently".

CREATE TABLE parent (id int, val int) PARTITION BY RANGE (id);
ALTER TABLE parent ADD CONSTRAINT val_positive CHECK (val > 0);
CREATE TABLE child PARTITION OF parent FOR VALUES FROM (1) TO (100);
ALTER TABLE child DROP CONSTRAINT val_positive;
-- ERROR: cannot drop inherited constraint "val_positive" of relation "child"

+      When a new partition is created, it generally inherits the current
+      definition-level properties of the parent partitioned table.

Maybe something like the following?

When a new partition is created, it generally inherits structural
properties of the parent partitioned table, such as column
definitions, constraints, and storage settings.

To be more explicit about what's inherited, and not only focus on
what's not. (The commit message also says that the change describes
both what's inherited and what's not inherited)

Thank you for the review!

On Fri, Jan 23, 2026 at 3:07 AM Zsolt Parragi <zsolt.parragi@percona.com>
wrote:

+ When applied to a partitioned table, the constraint is altered on the
+ partitioned table definition is implicitly applied to all partitions.

an "and" is missing here (definition and is)

Correct. But I'd go with:

...the constraint is altered on the partitioned table and implicitly
applied to all partitions.

+      When applied to a partitioned table, partition columns constraints
+      are implicitly renamed and specifying <literal>ONLY</literal>
is not allowed.
+     </para>

"partition columns constraints" - that seems like a strange/unclear
wording to me. maybe ", the partition's column constraints are ... " ?

This is just wrong - only is not permitted for either columns or
constraints. Only cannot be implicit if cascading is allowed.
The unclear wording noted is just missing an "and" - of the three things
that can be renamed (relation name, column name, constraint name) only
these two apply.
"the partition columns and constraints..."

<para>
When applied to a partitioned table, partition columns and constraints
are implicitly renamed.
Specifying <literal>ONLY</literal> is not allowed, and this command
cannot be used on individual partitions.
</para>
<para>
For inheritance setups, index-based constraints are always considered
independent. ~~Dependent columns and constraints are implicitly
renamed
and specifying <literal>ONLY</literal> is not allowed.~~
</para>

The last sentence is redundant with the notes though, I'd remove it as
noted above:

<para>
For inheritance setups, the behavior described for partitioned tables
applies
only to the dependent column(s) on the descendant table(s). It is
always
allowed to target a descendant table with column altering commands on
independent
columns.
</para>

But that note should have "dependent constraints" added to it.

+     <para>
+      When applied to a partitioned table <literal>ONLY</literal> is
implicit,
+      these forms must be applied separately to the partitioned table
and/or to
+      individual partitions.
+     </para>

"When applied to a partitioned table, <literal>ONLY</literal> is
implicit and ..." (at multiple places, this is an example)

I've grown unfond of my suggested wording here during reviews too. But
because it's too wordy and a bit redundant.

"When applied to a partitioned table ONLY is implicit, however, this
command can be used on individual partitions."

has a better symmetry with:

Specifying <literal>ONLY</literal> is not allowed, and this command cannot
be used on individual partitions.

"A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN)
never removes any descendant columns, but instead marks them as
independently defined rather than inherited."

This part is now undocumented, it was only mentioned in this paragraph.

True, it's left implied instead of explicitly stated. Any column that
exists on a child but not the parent is by definition "independently
defined". So if either ONLY is supplied or the rules for cascading delete
are not met the result is children with independently defined columns with
that name. The original note was wrong anyway for the two-parent case -
the second parent prevents the marking as independent when the first
parent's column is dropped.

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.

The documentation of this group is inconsistent.

DROP CONSTRAINT mentions that individual partitions can be dropped
separately:

+      When applied to a partitioned table, the constraint is dropped from
+      all existing partitions unless <literal>ONLY</literal> is specified.
+      Individual partitions may drop constraints independently of the
+      partitioned table.

But most of the sub commands in the C2 group leave the last sentence
out, and also the C7 (ADD table_constraint)

I didn't try and verify this dynamic or keep to it - though am on board
with considering changes that do so and remain accurate.

Also, isn't DROP CONSTRAINT on a partition limited to constraints
defined on that partition? So it would be better to say "may drop
constraints defined directly on that individual partition
independently".

"When applied to a partitioned table, dependent constraints are dropped
from ... is specified." should suffice.
I'd be fine leaving out the entire "Individual partitions may drop..."
business with that wording. It implies partitions may have independent
constraints which by extension may be targeted.

For Add Constraint - mention dependent constraints
"When applied to a partitioned table, the constraint is added to
the partitioned table and dependent constraints are added to all
partitions."

Which implies independent ones may exist and the logic for drop constraint
then follows.
(We should explain what happens if a partition already has an independent
constraint of the given name as that would be relevant here.)

CREATE TABLE parent (id int, val int) PARTITION BY RANGE (id);
ALTER TABLE parent ADD CONSTRAINT val_positive CHECK (val > 0);
CREATE TABLE child PARTITION OF parent FOR VALUES FROM (1) TO (100);
ALTER TABLE child DROP CONSTRAINT val_positive;
-- ERROR: cannot drop inherited constraint "val_positive" of relation
"child"

+      When a new partition is created, it generally inherits the current
+      definition-level properties of the parent partitioned table.

Maybe something like the following?

When a new partition is created, it generally inherits structural
properties of the parent partitioned table, such as column
definitions, constraints, and storage settings.

To be more explicit about what's inherited, and not only focus on
what's not. (The commit message also says that the change describes
both what's inherited and what's not inherited)

I concur with the premise but how about:

When a partition is created, it inherits many of the properties
of the parent table. However, properties related to ownership,
schema, replica identity, row-level security configuration,
per-attribute statistics targets, and per-attribute options
are not inherited.

"new" is superfluous on this page.
"definition-level" are the only kind of properties that exist - I'm not
being wordy thinking people might believe properties includes data.
"parent" suffices as well.
We did all the work to identify things - use "however" instead of "in
particular" to give us credit for the work.
Even if a property is explicitly set for the partition it isn't "inherited"
- the partition has its own independent value that in a rare case might
happen to match the parent at the time of creation. (i.e., remove
automatically and 'not inherited unless')
I'm not that inclined to mention the inclusion list. The general premise
of assuming inherited unless told otherwise works fine here; minimal
future-proofing.

David J.

On Fri, Jan 23, 2026 at 5:57 PM David G. Johnston <
david.g.johnston@gmail.com> wrote:

"A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN)
never removes any descendant columns, but instead marks them as
independently defined rather than inherited."

This part is now undocumented, it was only mentioned in this paragraph.

True, it's left implied instead of explicitly stated. Any column that
exists on a child but not the parent is by definition "independently
defined". So if either ONLY is supplied or the rules for cascading delete
are not met the result is children with independently defined columns with
that name.

The original note was wrong anyway for the two-parent case - the second
parent prevents the marking as independent when the first parent's column
is dropped.

Decided to test this one and I see the original wording was correct and we
will need to keep a note that in the two-parent ONLY case the un-dropped
children are marked both dependent and independent.

Change:

<para>
For inheritance setups, a descendant column is removed only if both
of the
following are true: this is the only parent defining the column, and
the column
was never independently defined in the descendant.
</para>

To:

"For inheritance setups, a descendant column is removed only if all the
following are true: ONLY is not specified, no other parent defines the
column, and the column is not marked as having been independent.
Otherwise, the descendant column is instead marked as having
been independent.

If we think that deserves a bit longer explanation about that/why/how a
column can be both dependent and "having been independent" we should
cross-reference to a more appropriate location. Here we just state this is
one way that condition can materialize.

David J.

On Jan 24, 2026, at 08:57, David G. Johnston <david.g.johnston@gmail.com> wrote:

Thank you for the review!

On Fri, Jan 23, 2026 at 3:07 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
+ When applied to a partitioned table, the constraint is altered on the
+ partitioned table definition is implicitly applied to all partitions.

an "and" is missing here (definition and is)

Correct. But I'd go with:

...the constraint is altered on the partitioned table and implicitly applied to all partitions.

Fixed with David’s version.

+      When applied to a partitioned table, partition columns constraints
+      are implicitly renamed and specifying <literal>ONLY</literal>
is not allowed.
+     </para>

"partition columns constraints" - that seems like a strange/unclear
wording to me. maybe ", the partition's column constraints are ... " ?

This is just wrong - only is not permitted for either columns or constraints. Only cannot be implicit if cascading is allowed.
The unclear wording noted is just missing an "and" - of the three things that can be renamed (relation name, column name, constraint name) only these two apply.
"the partition columns and constraints..."

<para>
When applied to a partitioned table, partition columns and constraints
are implicitly renamed.
Specifying <literal>ONLY</literal> is not allowed, and this command
cannot be used on individual partitions.
</para>
<para>
For inheritance setups, index-based constraints are always considered
independent. ~~Dependent columns and constraints are implicitly renamed
and specifying <literal>ONLY</literal> is not allowed.~~
</para>

The last sentence is redundant with the notes though, I'd remove it as noted above:

<para>
For inheritance setups, the behavior described for partitioned tables applies
only to the dependent column(s) on the descendant table(s). It is always
allowed to target a descendant table with column altering commands on independent
columns.
</para>

But that note should have "dependent constraints" added to it.

I added the missing “and”. And updated the “for inheritance” paragraph as suggested.

But for "Specifying <literal>ONLY</literal> is not allowed, and this command, cannot be used on individual partitions.”, that doesn’t seem correct. See my test:
```
evantest=# create table root (i int, j int) partition by list(i);
CREATE TABLE
evantest=# create table p1 partition of root for values in (1);
CREATE TABLE
evantest=# alter table p1 rename to pp1; <== Rename a partition is allowed.
ALTER TABLE
evantest=# alter table only pp1 rename to p1; <== ONLY can be used, but just no effect
ALTER TABLE
```

+     <para>
+      When applied to a partitioned table <literal>ONLY</literal> is implicit,
+      these forms must be applied separately to the partitioned table and/or to
+      individual partitions.
+     </para>

"When applied to a partitioned table, <literal>ONLY</literal> is
implicit and ..." (at multiple places, this is an example)

I've grown unfond of my suggested wording here during reviews too. But because it's too wordy and a bit redundant.

"When applied to a partitioned table ONLY is implicit, however, this command can be used on individual partitions."

has a better symmetry with:

Specifying <literal>ONLY</literal> is not allowed, and this command cannot be used on individual partitions.

"A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN)
never removes any descendant columns, but instead marks them as
independently defined rather than inherited."

This part is now undocumented, it was only mentioned in this paragraph.

True, it's left implied instead of explicitly stated. Any column that exists on a child but not the parent is by definition "independently defined". So if either ONLY is supplied or the rules for cascading delete are not met the result is children with independently defined columns with that name. The original note was wrong anyway for the two-parent case - the second parent prevents the marking as independent when the first parent's column is dropped.

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.

The documentation of this group is inconsistent.

DROP CONSTRAINT mentions that individual partitions can be dropped separately:

+      When applied to a partitioned table, the constraint is dropped from
+      all existing partitions unless <literal>ONLY</literal> is specified.
+      Individual partitions may drop constraints independently of the
+      partitioned table.

But most of the sub commands in the C2 group leave the last sentence
out, and also the C7 (ADD table_constraint)

I didn't try and verify this dynamic or keep to it - though am on board with considering changes that do so and remain accurate.

Also, isn't DROP CONSTRAINT on a partition limited to constraints
defined on that partition? So it would be better to say "may drop
constraints defined directly on that individual partition
independently".

"When applied to a partitioned table, dependent constraints are dropped from ... is specified." should suffice.
I'd be fine leaving out the entire "Individual partitions may drop..." business with that wording. It implies partitions may have independent constraints which by extension may be targeted.

For Add Constraint - mention dependent constraints
"When applied to a partitioned table, the constraint is added to the partitioned table and dependent constraints are added to all partitions."

Which implies independent ones may exist and the logic for drop constraint then follows.
(We should explain what happens if a partition already has an independent constraint of the given name as that would be relevant here.)

CREATE TABLE parent (id int, val int) PARTITION BY RANGE (id);
ALTER TABLE parent ADD CONSTRAINT val_positive CHECK (val > 0);
CREATE TABLE child PARTITION OF parent FOR VALUES FROM (1) TO (100);
ALTER TABLE child DROP CONSTRAINT val_positive;
-- ERROR: cannot drop inherited constraint "val_positive" of relation "child"

This is true. I updated the paragraph for DROP CONSTRAINT as:
```
<para>
When applied to a partitioned table, the constraint is dropped from
all existing partitions unless <literal>ONLY</literal> is specified.
Dropping an inherited constaint from an individual partition is not allowed.
</para>
```

+      When a new partition is created, it generally inherits the current
+      definition-level properties of the parent partitioned table.

Maybe something like the following?

When a new partition is created, it generally inherits structural
properties of the parent partitioned table, such as column
definitions, constraints, and storage settings.

To be more explicit about what's inherited, and not only focus on
what's not. (The commit message also says that the change describes
both what's inherited and what's not inherited)

I concur with the premise but how about:

When a partition is created, it inherits many of the properties
of the parent table. However, properties related to ownership,
schema, replica identity, row-level security configuration,
per-attribute statistics targets, and per-attribute options
are not inherited.

"new" is superfluous on this page.
"definition-level" are the only kind of properties that exist - I'm not being wordy thinking people might believe properties includes data.
"parent" suffices as well.
We did all the work to identify things - use "however" instead of "in particular" to give us credit for the work.
Even if a property is explicitly set for the partition it isn't "inherited" - the partition has its own independent value that in a rare case might happen to match the parent at the time of creation. (i.e., remove automatically and 'not inherited unless')
I'm not that inclined to mention the inclusion list. The general premise of assuming inherited unless told otherwise works fine here; minimal future-proofing.

I’m also not included to mention the inclusion list. My other patch [1]/messages/by-id/CAEoWx2nJ71hy8R614HQr7vQhkBReO9AANPODPg0aSQs74eOdLQ@mail.gmail.com is changing replica identity to be inherited. Go forward, the inclusion list should shrink.

So updated with David’s version.

PFA v7.

[1]: /messages/by-id/CAEoWx2nJ71hy8R614HQr7vQhkBReO9AANPODPg0aSQs74eOdLQ@mail.gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/