> On Jan 21, 2026, at 09:09, David G. Johnston <[email protected]>
> wrote:
>
> On Mon, Jan 19, 2026 at 1:20 AM Chao Li <[email protected]> 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/
