Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfS9m-001yzt-0e for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 00:21:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfS9l-001vET-0j for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 00:21:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfS9k-001vEL-2e for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 00:21:09 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfS9i-0007B9-2U for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 00:21:08 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-3ec47e4c20eso4409083fac.1 for ; Mon, 12 Jan 2026 16:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768263664; x=1768868464; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ydkOX//intS+Ncy9Kd6B0C0YqvefJRnl3BVhRU9g0P0=; b=azwzeFSMQNbxX9r7Y1qD3KCTsT1BwdqcMeBPwi0AXOGsbJLSJSSb1iPvpSQAgYbaoM i1qSKAaJnOmfjIYT5DTqI1w/PH6kAk3s+ziVgwRaYTU3V7fsEwEV0w5/M/OhfKkS9nUg hxoMN4d3ID9EVATFniEzG7oJPdivWqIwK/848T3h9GDZPTPSUZ7PW6RzIaVi4yUHI6cF Esbrr3VHZyNFkY/xrZoZcpReUrQLmPEpyE0/B9mIeT3ZP+TiHr/Nttd5IorF3D+5adOd yseRG5J85+XEcX377wYzXh+aMwUKb7zmtMIlUnfGG2Ghr7+lfXiZL4gsiJtBzM2WzcoR ECcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768263664; x=1768868464; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ydkOX//intS+Ncy9Kd6B0C0YqvefJRnl3BVhRU9g0P0=; b=w1oDHLAzTvHem/oDQwjk7s2IOj3+Qm2h2+uZHroztvA8nJzrT48TDnuCtFotps9fb9 FC890+T4x6Ac3OITHWzTNVOmXMQ3oGsKmhkccDBhSv2q2ZhIkErOE6CRzfC0d1Nq/Cw3 hZsXcrhcX5bsbkhpWcbdG7ambrYh500oUoZPoR3MOR/cFmq0WeFmUZB9JCwXop9FfQxI /BjyXovBRTn6rXumOpYATrLr1dpPO7drhWUOL/sjtxFBBnFlnxLKQDXV2EWmVjoMoO+F LqYZp6szmpadBhSvd/07rNjc/KEKz+d8mCqvCaHoycXz96fIwCVmQoPaVOY6Ignh4zMo s28g== X-Gm-Message-State: AOJu0YwgJH2A5F8VvIrLY05YFd9AODaIxO6A4poRDYFWRCmetPKKw9MG 1oTlO4sYiKGUUM/UAD4R3BkDF5TYgjmxbafyjd9MXH5VWvc4wJqKn7GiaUvDjxjwYzLM49Ka1Ta Z3kAWARQsOOEOnGaq0DboC1BJO+cehNTTRF17VoI= X-Gm-Gg: AY/fxX4cMC3ZHgY9xBncZ21QZC2Yh+Bmws2KErqWIIry5G+qdzgHtPzKCyUYMYWtX1I aoTOTFJKu3JRf4mZImy5wcCqOO52QGyJVLGiEE1MndqcVa4ZqDNvZkmDS3L8yKa4rza1DIulxao 8Yl/fsTHT78MCVaIgFEjJoGQNMY3CzhekcHu119qPVixlUubf0Wu/aVmUW6/rVHalhKKmfEwCUT +VxuZEJlSzEvGj0aGOEnHdbRrhl36PvbQmCAKUh2wOJDu+w3IAm9bNKu3oPF1Kk1F/HXFOA X-Google-Smtp-Source: AGHT+IG+lWkReTyjNJTpES5RJMxStJdzoWFlnet3m7eIPLpAfl9qls4+x0Yh8HCILX0Tr5A+/Mt7pB0SPTbfJroYIXQ= X-Received: by 2002:a05:6870:249:b0:3e8:8e56:671b with SMTP id 586e51a60fabf-3ffc0bb26d9mr9227786fac.55.1768263664466; Mon, 12 Jan 2026 16:21:04 -0800 (PST) MIME-Version: 1.0 References: <90F9169D-135C-45E5-8221-4F79DAED98E2@gmail.com> <46DA7611-C18D-4782-AEFF-F861ECDEFA5C@gmail.com> In-Reply-To: <46DA7611-C18D-4782-AEFF-F861ECDEFA5C@gmail.com> From: "David G. Johnston" Date: Mon, 12 Jan 2026 17:20:28 -0700 X-Gm-Features: AZwV_QiVSr1wQkbOGxVi6vG4aN4D2sSGTUKuxWFlDRt6_N-HUnf6VTd7NwPkT1U Message-ID: Subject: Re: docs: clarify ALTER TABLE behavior on partitioned tables To: Chao Li Cc: Postgres hackers , Amit Kapila Content-Type: multipart/alternative; boundary="00000000000097005d064839f792" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000097005d064839f792 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 11, 2026 at 10:52=E2=80=AFPM Chao Li w= rote: > > [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=E2=80=99d like to sugge= st 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 not= e > that some actions may behave differently, with details described in each > action=E2=80=99s 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. We should not be documenting "ideal behavior" - only actual behavior. 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 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. David J. --00000000000097005d064839f792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jan 11, 2026 at 10:52=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wrote:<= /span>

[1]=C2=A0 https://postgr.es/m/59FB= 38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com
If we stop here, these in= consistencies will remain indefinitely, which I believe nobody really wants= . With that in mind, I=E2=80=99d like to suggest a two-phase approach.
<= br>Phase 1: Document current behavior and set expectations

* Identif= y all ALTER TABLE actions involved in these inconsistencies.
* Update th= e ALTER TABLE and CREATE TABLE documentation to clearly describe the curren= t behavior for partitioned tables, and (where appropriate) the intended or = ideal behavior.
* Explicitly document the meaning of ONLY for partitione= d tables, and note that some actions may behave differently, with details d= escribed in each action=E2=80=99s section.

I = agree, we should modify alter to note the cascade and/or non-cascade scenar= ios and modify=C2=A0create to note the things that are (not) inherited.=C2= =A0 I'm fine with the "newly created" stuff being put into cr= eate table instead of touching 5.12.

We should not be = documenting "ideal behavior" - only actual behavior.

=
We should indeed document that ONLY, if added to an alter command = that would cascade to partitions, prevents that cascading.=C2=A0 If added t= o a command that wouldn't cascade anyway it is usually accepted as just= specifying the default behavior.=C2=A0 There is no way to indicate explici= tly that one wishes to cascade.

I still have my doubts= whether changing long-standing behavior is going to happen.=C2=A0 But that= is also fairly immaterial since best practice is to proceed without even t= rying to predict the future and instead just deal with what is in front of = us right now.

David J.

--00000000000097005d064839f792--