Re: docs: clarify ALTER TABLE behavior on partitioned tables

> On Jan 21, 2026, at 09:09, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> On Mon, Jan 19, 2026 at 1:20 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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/