Re: docs: clarify ALTER TABLE behavior on partitioned tables

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: docs: clarify ALTER TABLE behavior on partitioned tables
Date: 2026-01-13 06:27:51
Message-ID: CAEoWx2mUiCYJEBuo5D74gi7pHfNz82b54oDHjZNtrXRFDnBPOg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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

[1] https://postgr.es/m/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.

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/

Attachment Content-Type Size
v3-0001-docs-clarify-ALTER-TABLE-behavior-on-partitioned-.patch application/octet-stream 33.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Soumya S Murali 2026-01-13 06:29:43 Re: [PATCH] Expose checkpoint reason to completion log messages.
Previous Message li carol 2026-01-13 06:15:54 RE: PL/Python initialization cleanup