Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\))
Subject: Re: docs: clarify ALTER TABLE behavior on partitioned tables
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <CAKFQuwZyJNBN+N5Qtcg0aG6ZpOFvQV5m=cALLgv7g3u1Sz-tZw@mail.gmail.com>
Date: Wed, 21 Jan 2026 10:53:43 +0800
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
 Amit Kapila <amit.kapila16@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <245AA9F3-7577-46D6-990C-C308A9F36E82@gmail.com>
References: <CAEoWx2=mYhCfsnHaN96Qqwq5b0GVS2YgO3zpVqPPRd_iO52wRw@mail.gmail.com>
 <90F9169D-135C-45E5-8221-4F79DAED98E2@gmail.com>
 <CAKFQuwbWNCX1M1e9_-3P9RVGo10huPjuqdL74FJ+-a5EW791KA@mail.gmail.com>
 <D559C6FA-E101-47F3-BCDF-CEA7FFDF6154@gmail.com>
 <CAKFQuwZ+o6La5DyK9_-L2gpeiKNvGMbR78UjocO4++JkyZaRHw@mail.gmail.com>
 <A8FA43A6-415E-421A-B3EC-CAB68756975D@gmail.com>
 <CAKFQuwabxFyFQob=RfKOV3upjxwomAzmGzSouN-h2ypuXz+dZg@mail.gmail.com>
 <46DA7611-C18D-4782-AEFF-F861ECDEFA5C@gmail.com>
 <CAKFQuwZaquUrTOhfmJ2CenwiyAHx4nORQ0kB01sL+z5pCBuLFQ@mail.gmail.com>
 <CAEoWx2mUiCYJEBuo5D74gi7pHfNz82b54oDHjZNtrXRFDnBPOg@mail.gmail.com>
 <CAKFQuwbQ=L8w8jEaB8_gW-RrNv2_V-VrFYBump7__z-vh-QJWw@mail.gmail.com>
 <CAEoWx2nwoBtWX3=UOQQpGZOuRH5vNv2PHqeFHqDPdiKGaOigiA@mail.gmail.com>
 <CAKFQuwZyJNBN+N5Qtcg0aG6ZpOFvQV5m=cALLgv7g3u1Sz-tZw@mail.gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/245AA9F3-7577-46D6-990C-C308A9F36E82%40gmail.com>
Precedence: bulk


> On Jan 21, 2026, at 09:09, David G. Johnston =
<david.g.johnston@gmail.com> wrote:
>=20
> On Mon, Jan 19, 2026 at 1:20=E2=80=AFAM Chao Li =
<li.evan.chao@gmail.com> wrote:
>=20
> 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?
>=20
>=20
> v5 Attached with a delta.
>=20
> 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.
>=20
> David J.
>=20
> =
<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 =E2=80=9Conly=
 if both:=E2=80=9D, 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 =E2=80=9Cspecifying ONLY is not allowed=E2=80=9D is wrong. ONLY can =
be specified, but has no effect. So I think we can use the statement you =
put to ENABLE/DISABLE TRIGGER: =E2=80=9CONLY is implied, though it may =
be specified=E2=80=9D.

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/