Re: docs: clarify ALTER TABLE behavior on partitioned tables - Mailing list pgsql-hackers

> 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
pleasemark 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
inheritancesetups.  I put a note in place of the removals pointing out that when inheritance is being used for
partitioningthe rules for partitioned tables apply (implied 'unless otherwise noted') and that local/independent
objectscan always be addressed normally.  I then incorporated the notes into the appropriate sub-command sections.
Pleasegive 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
statementyou 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/