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 1vjSGu-00FOSk-0p for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Jan 2026 01:17:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjSGt-0021qy-0q for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Jan 2026 01:17:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjSGs-0021qp-2T for pgsql-hackers@lists.postgresql.org; Sat, 24 Jan 2026 01:17:03 +0000 Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vjSGq-001zeQ-0V for pgsql-hackers@lists.postgresql.org; Sat, 24 Jan 2026 01:17:02 +0000 Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-45c7a6de470so730156b6e.3 for ; Fri, 23 Jan 2026 17:17:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769217420; cv=none; d=google.com; s=arc-20240605; b=ftKrEoirwWQJa7CYR2TInwdDm849oKlz4/pjO7Ngj6nendeY9ZbJuU4S34sW7H63P6 JGU1Wpv6PmvA+vLIXU1l88Q5vlENEM3JQFdQYXnhjiW6ZRhMj7kocFL7BUuAGBegZHh3 oCHJgYghCwCk5CHHKFL74ge67TnV8d2RagNnP91NcM7wtWACB9c4CuSiyM3oszcf+OLu 7Tk7OAL70MilzkxAzV6xR9Ehqfz7JBwn5H6YlvLGC5IPRTO9EFliZFHRPxUCh/dkZQ1F VW4Hk+kkv+35v5WZMEvPRpByjpjRa5xW2M7xwUZyMmby02MZiJ2a2PGhUqkX79XZKEsa I0HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=cjdBeI6GkuJFQteFfhyfFKJtTLuGRLsenFebQk6qnIc=; fh=y6gi/HF50yHmsezSFRfM89ArLZO6Ty7jWiiU45diCJQ=; b=SQxi9lU/tG4stfmvjek3bzuEXwdfv8ky9WxcPCIgKwv0Nvm4svJ4s47ftcpQIfaNBQ SP1FYVSaLqWpoKTtOqtloNiHUtzUoWH6fiiJLk5LE9/iiOXZwyhvlD+vy68DedrIOPhA PPOwY1aTHResd65GWkR46tOivKuJxNoGculXMrdl4P8CzJ38t/hRSBs5dcVtJomOiq5d UGO49/LaKNzf/igny2STwrWZn0d5eg6GtJTnrxm2FqrLkiGTmYXKXDXbO8ql+7CvEfu1 FyiZvR1+0znA2ypTzixXSSQKUoC29T/xOEbP3fwq3qZQpTuDKMWqwPjtlXms0HdEALw1 ejpQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769217420; x=1769822220; 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=cjdBeI6GkuJFQteFfhyfFKJtTLuGRLsenFebQk6qnIc=; b=fGvAPi44/mgWA3XW9Eox5oCa98G59UujQSh48Lgxe1tzitIWTXNcXzKVwkcmZrZDJa 7gNiyTcnLG4AxHIi1vHPidWxsgxbWdcZuIJkaM4ZwAwLxsJChDQfdqYlyKrR0hH6T5uK CEWRddQbKuSZrpNV8XZeEGhKb6DKoWotzriUbHIjRXvYps0LwHMR7PGDGqfM9yqAuxJc m7gfNgP8lM/Wfv5yURvd5SEYPzLKxZ8+SRvlVBCx+Gk/VAL6GAFEm8vKzoJfHeXjOCjA Kg4es2yS0kREAGEe8UwLYabp7RX7U15QkzHZ3OCQADA5eOriMsAJOj0r5nCfW2k334+o QEog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769217420; x=1769822220; 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=cjdBeI6GkuJFQteFfhyfFKJtTLuGRLsenFebQk6qnIc=; b=cNaOJHpF5uPV6QfSaYI1vvk1mD0790C1698ynOa7P8Fo4jDMdmxB4S0e+PGgJSStGE vnl5y52nvVed3/JXSDW91mI42MK3gc6NDJ0FOdh1lhy1w9uBKBbcZg0fXIVuPbvcPYS9 9jckTRUzr08DpliO9T7/sdVJjTu9hbiiRkF0dH7pMEKl4MK05BawEnreOypc9IhinY0O B6FP8JX2Q/+cegWTpaQhweAymXnAttramlb162iyd6uovSdMrOFKE/QKf4Or3zO0bzkS cQN70vBJCOorTCaAs2rnewoiak2zZ6iZqvQTeXoDWnrLzxD5s4Ni/9JN07L5uQ/i/YHt gYJw== X-Forwarded-Encrypted: i=1; AJvYcCV0wnG7GiB4D8bDJa5TDCE6Grej8ONG829rgYz2RPECWERH7jMXyjw4dFt7vRAaCMDjkJ34s4tLRz17bB0d@lists.postgresql.org X-Gm-Message-State: AOJu0YzQ4P2H803yzgG7VrCGzlSBdWnvYU1OIcdYNSFIrug/cOO1FMy7 Abr0+1u3vIFDlc8MVTcH4p3v57JpVsxkDgr5lNsElvBWVaNWJeJIOuYyX9ddoMXLRUnXQy9ljsF Qje3TWS8WB+k9+ttbsqzh2m3SFUlsTz4= X-Gm-Gg: AZuq6aIt+T9nGB6iZ3tHxuXNzx0TdUPRF7FYBxbWCWiIHjuzGrnejrCqWqnaAyToXVk Gslji3miqGOxg3tZUzCf8hDWGVqrfUV78vf682ymyohmRQGaLer4VfkCre//A6oxTm2qmXNNiJA vYBVFHPMy6rlhtq6pnyU8K7lMo8Myo+PVzoosCHqVNvMepO8RAw0URx0HXIkWbOH9MfFcww+STR c7P23r+FPeOkW+wc0zSypdgOrL9FLVx6mfDesD42NcuTvGRgHkudrnDLoJzKzy6nfv6+iG0KvKV 75u64XA= X-Received: by 2002:a05:6830:7317:b0:7cf:d9bb:63a1 with SMTP id 46e09a7af769-7d15a5d9e7cmr2515067a34.16.1769217420101; Fri, 23 Jan 2026 17:17:00 -0800 (PST) MIME-Version: 1.0 References: <90F9169D-135C-45E5-8221-4F79DAED98E2@gmail.com> <46DA7611-C18D-4782-AEFF-F861ECDEFA5C@gmail.com> <245AA9F3-7577-46D6-990C-C308A9F36E82@gmail.com> In-Reply-To: From: "David G. Johnston" Date: Fri, 23 Jan 2026 18:16:23 -0700 X-Gm-Features: AZwV_Qi_E6d-4Ie-DhxHULlWWXmG_foEFai6oeJwaw1M2rXbsMJaX8hEE8EzNxo Message-ID: Subject: Re: docs: clarify ALTER TABLE behavior on partitioned tables To: Zsolt Parragi Cc: Chao Li , Postgres hackers , Amit Kapila Content-Type: multipart/alternative; boundary="000000000000db0a4d06491807c9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000db0a4d06491807c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 23, 2026 at 5:57=E2=80=AFPM David G. Johnston < david.g.johnston@gmail.com> wrote: > >> "A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN) >> never removes any descendant columns, but instead marks them as >> independently defined rather than inherited." >> >> This part is now undocumented, it was only mentioned in this paragraph. >> > > True, it's left implied instead of explicitly stated. Any column that > exists on a child but not the parent is by definition "independently > defined". So if either ONLY is supplied or the rules for cascading delet= e > are not met the result is children with independently defined columns wit= h > that name. > > The original note was wrong anyway for the two-parent case - the second > parent prevents the marking as independent when the first parent's column > is dropped. > Decided to test this one and I see the original wording was correct and we will need to keep a note that in the two-parent ONLY case the un-dropped children are marked both dependent and independent. Change: 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. To: "For inheritance setups, a descendant column is removed only if all the following are true: ONLY is not specified, no other parent defines the column, and the column is not marked as having been independent. Otherwise, the descendant column is instead marked as having been independent. If we think that deserves a bit longer explanation about that/why/how a column can be both dependent and "having been independent" we should cross-reference to a more appropriate location. Here we just state this is one way that condition can materialize. David J. --000000000000db0a4d06491807c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Ja= n 23, 2026 at 5:57=E2=80=AFPM David G. Johnston <david.g.johnston@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

"A nonrecursive DROP COLUMN (i.e., ALTER TABLE ONLY ... DROP COLUMN) never removes any descendant columns, but instead marks them as
independently defined rather than inherited."

This part is now undocumented, it was only mentioned in this paragraph.
=

True, it's left implied instead of explicitly stated.=C2=A0 Any = column that exists on a child but not the parent is by definition "ind= ependently defined".=C2=A0 So if either ONLY is supplied or the rules = for cascading delete are not met the result is children with independently = defined columns with that name.

=C2=A0
The original note was wrong anyway for the two-parent case= - the second parent prevents the marking as independent when the first par= ent's column is dropped.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Decided to test this one and I see the original wording was correct and w= e will need to keep a note that in the two-parent ONLY case the un-dropped = children are marked both dependent and independent.

Ch= ange:

=C2=A0 =C2=A0 =C2=A0<para>
=C2=A0 =C2= =A0 =C2=A0 For inheritance setups, a descendant column is removed only if b= oth of the
=C2=A0 =C2=A0 =C2=A0 following are true: this is the only par= ent defining the column, and the column
=C2=A0 =C2=A0 =C2=A0 was never i= ndependently defined in the descendant.
=C2=A0 =C2=A0 =C2=A0</para>= ;

To:

"For inheritance setup= s, a descendant column is removed only if all the following are true: ONLY = is not specified, no other parent defines the column, and the column is not= marked as having been independent.=C2=A0 Otherwise, the descendant column = is instead marked as having been=C2=A0independent.

If = we think that deserves a bit longer explanation about that/why/how a column= can be both dependent and "having been independent" we should cr= oss-reference to a more appropriate location.=C2=A0 Here we just state this= is one way that condition can materialize.

David J.

--000000000000db0a4d06491807c9--