MIME-Version: 1.0
From: Chao Li <li.evan.chao@gmail.com>
Date: Mon, 12 Jan 2026 17:02:19 +0800
Message-ID: <CAEoWx2=SLga-xH09Cq_PAvsHhQHrBK+V0vF821JKgzS=Bm0haA@mail.gmail.com>
Subject: ALTER TABLE: warn when actions do not recurse to partitions
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000a8ed1706482d22d2"
Archived-At: <https://www.postgresql.org/message-id/CAEoWx2%3DSLga-xH09Cq_PAvsHhQHrBK%2BV0vF821JKgzS%3DBm0haA%40mail.gmail.com>
Precedence: bulk

--000000000000a8ed1706482d22d2
Content-Type: multipart/alternative; boundary="000000000000a8ed1506482d22d0"

--000000000000a8ed1506482d22d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Hacker,

This patch is part of a broader effort to make ALTER TABLE actions behave
more consistently with respect to partitioned tables. There has been
ongoing discussion around this area; see [1], which also links to earlier
related threads.

In short, changing ALTER TABLE semantics requires more discussion and
coordination than a single patch can realistically achieve. Before that
larger work happens, I=E2=80=99m following up on [1] by trying to clarify t=
he
current behavior, both in documentation and in user-facing feedback.

This patch adds warning messages for sub-commands that appear to recurse
but in fact do not. These currently include:

* SET STATISTICS
* SET/RESET (attribute_option =3D value)
* ENABLE/DISABLE [ REPLICA | ALWAYS] RULE
* ENABLE/DISABLE ROW LEVEL SECURITY
* NO FORCE / FORCE ROW LEVEL SECURITY
* OWNER TO
* REPLICA IDENTITY
* SET SCHEMA

For example, if a user runs:
```
ALTER TABLE ONLY a_partitioned_table REPLICA IDENTITY FULL;
```
the semantics are clear: only the partitioned table itself is modified.

However, if the user runs the same command without ONLY:
```
ALTER TABLE a_partitioned_table REPLICA IDENTITY FULL;
```
there is potential confusion. From the command syntax alone, it is
reasonable to assume that the change would propagate to child partitions,
but in reality, it does not. Since the ALTER TABLE documentation does not
explicitly spell this out, users often need to test the behavior themselves
to be sure, which is a poor user experience.

With this patch, the command instead emits a warning such as:
```
evantest=3D# alter table sensor_data replica identity full;
WARNING:  REPLICA IDENTITY is only applied to the partitioned table itself
ALTER TABLE
```
This makes the behavior explicit and removes the ambiguity.

For now, I=E2=80=99ve limited the change to REPLICA IDENTITY to see whether=
 there
are objections to this approach. If there are none, I plan to extend the
same warning behavior to the other sub-commands listed above. After that,
users can reasonably assume that an ALTER TABLE partitioned_table
... action will recurse to child partitions unless a warning explicitly
tells them otherwise.

[1] https://postgr.es/m/59FB38EF-FA62-41B7-A082-DDA251B04F9E@gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

--000000000000a8ed1506482d22d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto" style=3D"line-break:after-white-space"><=
div>Hi Hacker,</div><div><br></div><div>This patch is part of a broader eff=
ort to make=C2=A0ALTER TABLE=C2=A0actions behave more=C2=A0consistently=C2=
=A0with respect to partitioned tables. There has been ongoing discussion ar=
ound this area; see [1], which also links to earlier related threads.</div>=
<div><br>In short, changing=C2=A0ALTER TABLE=C2=A0semantics requires more d=
iscussion and coordination than a single patch can realistically achieve. B=
efore that larger work happens, I=E2=80=99m following up on [1] by trying t=
o=C2=A0clarify the current behavior, both in documentation and in user-faci=
ng feedback.</div><div><br>This patch adds=C2=A0warning messages=C2=A0for s=
ub-commands that=C2=A0appear=C2=A0to recurse but in fact=C2=A0do not. These=
 currently include:</div><div><br></div><div>* SET STATISTICS<br>* SET/RESE=
T (attribute_option =3D value)<br>* ENABLE/DISABLE [ REPLICA | ALWAYS] RULE=
<br>* ENABLE/DISABLE ROW LEVEL SECURITY<br>* NO FORCE / FORCE ROW LEVEL SEC=
URITY<br>* OWNER TO<br>* REPLICA IDENTITY<br>* SET SCHEMA</div><div><br></d=
iv><div>For example, if a user runs:</div><div>```</div><div>ALTER TABLE ON=
LY a_partitioned_table REPLICA IDENTITY FULL;</div><div>```</div><div>the s=
emantics are clear: only the partitioned table itself is modified.</div><di=
v><br>However, if the user runs the same command=C2=A0without=C2=A0ONLY:</d=
iv><div>```</div><div>ALTER TABLE a_partitioned_table REPLICA IDENTITY FULL=
;<br>```</div><div>there is potential confusion. From the command syntax al=
one, it is reasonable to assume that the change would propagate to child pa=
rtitions, but in reality, it does not. Since the=C2=A0ALTER TABLE=C2=A0docu=
mentation does not explicitly spell this out, users often need to test the =
behavior themselves to be sure, which is a poor user experience.</div><div>=
<br></div><div>With this patch, the command instead emits a warning such as=
:</div><div>```</div><div><div>evantest=3D# alter table sensor_data replica=
 identity full;</div><div>WARNING: =C2=A0REPLICA IDENTITY is only applied t=
o the partitioned table itself</div><div>ALTER TABLE</div></div><div>```</d=
iv><div>This makes the behavior explicit and removes the ambiguity.</div><d=
iv><br>For now, I=E2=80=99ve limited the change to=C2=A0REPLICA IDENTITY=C2=
=A0to see whether there are objections to this approach. If there are none,=
 I plan to extend the same warning behavior to the other sub-commands liste=
d above. After that, users can reasonably assume that an=C2=A0ALTER TABLE p=
artitioned_table ...=C2=A0action will recurse to child partitions=C2=A0unle=
ss=C2=A0a warning explicitly tells them otherwise.</div><div><br></div><div=
>[1]=C2=A0<a href=3D"https://postgr.es/m/59FB38EF-FA62-41B7-A082-DDA251B04F=
9E@gmail.com" target=3D"_blank">https://postgr.es/m/59FB38EF-FA62-41B7-A082=
-DDA251B04F9E@gmail.com</a></div><div><br></div>Best regards,<br><div id=3D=
"m_-7403956551156194668AppleMailSignature">
--<br>Chao Li (Evan)<br>HighGo Software Co., Ltd.<br><a href=3D"https://www=
.highgo.com/" target=3D"_blank">https://www.highgo.com/</a><br><br><br><br>

</div>
<br></div></div>

--000000000000a8ed1506482d22d0--
--000000000000a8ed1706482d22d2
Content-Type: application/octet-stream; 
	name="v1-0001-Add-warning-when-ALTER-TABLE-REPLICA-IDENTITY-doe.patch"
Content-Disposition: attachment; 
	filename="v1-0001-Add-warning-when-ALTER-TABLE-REPLICA-IDENTITY-doe.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mkaxmp4t0>
X-Attachment-Id: f_mkaxmp4t0

RnJvbSAxOWFiYjJhNTJkZDc3OGE1YzE1MjU0ZjQxY2IxYmFlMDIyMjc0N2JjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiAiQ2hhbyBMaSAoRXZhbikiIDxsaWNAaGlnaGdvLmNvbT4KRGF0
ZTogTW9uLCAxMiBKYW4gMjAyNiAxNjo1Njo1OCArMDgwMApTdWJqZWN0OiBbUEFUQ0ggdjFdIEFk
ZCB3YXJuaW5nIHdoZW4gQUxURVIgVEFCTEUgUkVQTElDQSBJREVOVElUWSBkb2VzIG5vdAogcmVj
dXJzZQoKQUxURVIgVEFCTEUgLi4uIFJFUExJQ0EgSURFTlRJVFkgYWNjZXB0cyBhIHJlY3Vyc2l2
ZSBmb3JtIG9uCnBhcnRpdGlvbmVkIHRhYmxlcywgYnV0IHRoZSBjaGFuZ2UgaXMgYXBwbGllZCBv
bmx5IHRvIHRoZSBwYXJ0aXRpb25lZAp0YWJsZSBpdHNlbGYgYW5kIGRvZXMgbm90IHByb3BhZ2F0
ZSB0byBjaGlsZCBwYXJ0aXRpb25zLgoKUHJldmlvdXNseSB0aGlzIGNhc2Ugd2FzIHNpbGVudGx5
IGFjY2VwdGVkLCB3aGljaCBjb3VsZCBtaXNsZWFkIHVzZXJzCmludG8gYXNzdW1pbmcgdGhhdCB0
aGUgc2V0dGluZyB3b3VsZCByZWN1cnNlLiBBZGQgYSB3YXJuaW5nIHdoZW4KcmVjdXJzaW9uIGlz
IHJlcXVlc3RlZCBvbiBhIHBhcnRpdGlvbmVkIHRhYmxlIHRvIG1ha2UgdGhlIGJlaGF2aW9yCmV4
cGxpY2l0IGFuZCBhdm9pZCBjb25mdXNpb24uCgpUaGlzIGNoYW5nZSBkb2VzIG5vdCBhbHRlciBz
ZW1hbnRpY3M7IGl0IG9ubHkgcHJvdmlkZXMgdXNlci12aXNpYmxlCmZlZWRiYWNrLiBTaW1pbGFy
IHdhcm5pbmdzIG1heSBiZSBhZGRlZCBmb3Igb3RoZXIgQUxURVIgVEFCTEUKc3ViLWNvbW1hbmRz
IHdpdGggbm9uLXJlY3Vyc2l2ZSBiZWhhdmlvciBpbiBmb2xsb3ctdXAgY29tbWl0cy4KCkF1dGhv
cjogQ2hhbyBMaSA8bGljQGhpZ2hnby5jb20+Ci0tLQogc3JjL2JhY2tlbmQvY29tbWFuZHMvdGFi
bGVjbWRzLmMgfCAyMiArKysrKysrKysrKysrKysrKy0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTcg
aW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9j
b21tYW5kcy90YWJsZWNtZHMuYyBiL3NyYy9iYWNrZW5kL2NvbW1hbmRzL3RhYmxlY21kcy5jCmlu
ZGV4IGY5NzZjMGU1YzdlLi40MGE0ZDMwODMzNCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvY29t
bWFuZHMvdGFibGVjbWRzLmMKKysrIGIvc3JjL2JhY2tlbmQvY29tbWFuZHMvdGFibGVjbWRzLmMK
QEAgLTY5Myw3ICs2OTMsNyBAQCBzdGF0aWMgdm9pZCBkcm9wX3BhcmVudF9kZXBlbmRlbmN5KE9p
ZCByZWxpZCwgT2lkIHJlZmNsYXNzaWQsIE9pZCByZWZvYmppZCwKIAkJCQkJCQkJICAgRGVwZW5k
ZW5jeVR5cGUgZGVwdHlwZSk7CiBzdGF0aWMgT2JqZWN0QWRkcmVzcyBBVEV4ZWNBZGRPZihSZWxh
dGlvbiByZWwsIGNvbnN0IFR5cGVOYW1lICpvZlR5cGVuYW1lLCBMT0NLTU9ERSBsb2NrbW9kZSk7
CiBzdGF0aWMgdm9pZCBBVEV4ZWNEcm9wT2YoUmVsYXRpb24gcmVsLCBMT0NLTU9ERSBsb2NrbW9k
ZSk7Ci1zdGF0aWMgdm9pZCBBVEV4ZWNSZXBsaWNhSWRlbnRpdHkoUmVsYXRpb24gcmVsLCBSZXBs
aWNhSWRlbnRpdHlTdG10ICpzdG10LCBMT0NLTU9ERSBsb2NrbW9kZSk7CitzdGF0aWMgdm9pZCBB
VEV4ZWNSZXBsaWNhSWRlbnRpdHkoUmVsYXRpb24gcmVsLCBSZXBsaWNhSWRlbnRpdHlTdG10ICpz
dG10LCBib29sIHJlY3Vyc2UsIExPQ0tNT0RFIGxvY2ttb2RlKTsKIHN0YXRpYyB2b2lkIEFURXhl
Y0dlbmVyaWNPcHRpb25zKFJlbGF0aW9uIHJlbCwgTGlzdCAqb3B0aW9ucyk7CiBzdGF0aWMgdm9p
ZCBBVEV4ZWNTZXRSb3dTZWN1cml0eShSZWxhdGlvbiByZWwsIGJvb2wgcmxzKTsKIHN0YXRpYyB2
b2lkIEFURXhlY0ZvcmNlTm9Gb3JjZVJvd1NlY3VyaXR5KFJlbGF0aW9uIHJlbCwgYm9vbCBmb3Jj
ZV9ybHMpOwpAQCAtNTIyNyw4ICs1MjI3LDE1IEBAIEFUUHJlcENtZChMaXN0ICoqd3F1ZXVlLCBS
ZWxhdGlvbiByZWwsIEFsdGVyVGFibGVDbWQgKmNtZCwKIAkJCUFUU2ltcGxlUGVybWlzc2lvbnMo
Y21kLT5zdWJ0eXBlLCByZWwsCiAJCQkJCQkJCUFUVF9UQUJMRSB8IEFUVF9QQVJUSVRJT05FRF9U
QUJMRSB8IEFUVF9NQVRWSUVXKTsKIAkJCXBhc3MgPSBBVF9QQVNTX01JU0M7Ci0JCQkvKiBUaGlz
IGNvbW1hbmQgbmV2ZXIgcmVjdXJzZXMgKi8KLQkJCS8qIE5vIGNvbW1hbmQtc3BlY2lmaWMgcHJl
cCBuZWVkZWQgKi8KKworCQkJLyoKKwkJCSAqIFRoaXMgY29tbWFuZCBub3cgZG9lc24ndCByZWN1
cnNlLCBidXQgd2Ugd2FudCB0byBub3RpZnkgdXNlciBpZgorCQkJICogcmVjdXJzZSBpcyBzZXQK
KwkJCSAqCisJCQkgKiBObyBjb21tYW5kLXNwZWNpZmljIHByZXAgbmVlZGVkCisJCQkgKi8KKwkJ
CWlmIChyZWN1cnNlKQorCQkJCWNtZC0+cmVjdXJzZSA9IHRydWU7CiAJCQlicmVhazsKIAkJY2Fz
ZSBBVF9FbmFibGVUcmlnOgkJLyogRU5BQkxFIFRSSUdHRVIgdmFyaWFudHMgKi8KIAkJY2FzZSBB
VF9FbmFibGVBbHdheXNUcmlnOgpAQCAtNTY0Myw3ICs1NjUwLDggQEAgQVRFeGVjQ21kKExpc3Qg
Kip3cXVldWUsIEFsdGVyZWRUYWJsZUluZm8gKnRhYiwKIAkJCUFURXhlY0Ryb3BPZihyZWwsIGxv
Y2ttb2RlKTsKIAkJCWJyZWFrOwogCQljYXNlIEFUX1JlcGxpY2FJZGVudGl0eToKLQkJCUFURXhl
Y1JlcGxpY2FJZGVudGl0eShyZWwsIChSZXBsaWNhSWRlbnRpdHlTdG10ICopIGNtZC0+ZGVmLCBs
b2NrbW9kZSk7CisJCQlBVEV4ZWNSZXBsaWNhSWRlbnRpdHkocmVsLCAoUmVwbGljYUlkZW50aXR5
U3RtdCAqKSBjbWQtPmRlZiwKKwkJCQkJCQkJICBjbWQtPnJlY3Vyc2UsIGxvY2ttb2RlKTsKIAkJ
CWJyZWFrOwogCQljYXNlIEFUX0VuYWJsZVJvd1NlY3VyaXR5OgogCQkJQVRFeGVjU2V0Um93U2Vj
dXJpdHkocmVsLCB0cnVlKTsKQEAgLTE4NTE1LDEyICsxODUyMywxNiBAQCByZWxhdGlvbl9tYXJr
X3JlcGxpY2FfaWRlbnRpdHkoUmVsYXRpb24gcmVsLCBjaGFyIHJpX3R5cGUsIE9pZCBpbmRleE9p
ZCwKICAqIEFMVEVSIFRBQkxFIDxuYW1lPiBSRVBMSUNBIElERU5USVRZIC4uLgogICovCiBzdGF0
aWMgdm9pZAotQVRFeGVjUmVwbGljYUlkZW50aXR5KFJlbGF0aW9uIHJlbCwgUmVwbGljYUlkZW50
aXR5U3RtdCAqc3RtdCwgTE9DS01PREUgbG9ja21vZGUpCitBVEV4ZWNSZXBsaWNhSWRlbnRpdHko
UmVsYXRpb24gcmVsLCBSZXBsaWNhSWRlbnRpdHlTdG10ICpzdG10LCBib29sIHJlY3Vyc2UsIExP
Q0tNT0RFIGxvY2ttb2RlKQogewogCU9pZAkJCWluZGV4T2lkOwogCVJlbGF0aW9uCWluZGV4UmVs
OwogCWludAkJCWtleTsKIAorCWlmIChyZWN1cnNlICYmIHJlbC0+cmRfcmVsLT5yZWxraW5kID09
IFJFTEtJTkRfUEFSVElUSU9ORURfVEFCTEUpCisJCWVyZXBvcnQoV0FSTklORywKKwkJCQkoZXJy
bXNnKCJSRVBMSUNBIElERU5USVRZIGlzIG9ubHkgYXBwbGllZCB0byB0aGUgcGFydGl0aW9uZWQg
dGFibGUgaXRzZWxmIikpKTsKKwogCWlmIChzdG10LT5pZGVudGl0eV90eXBlID09IFJFUExJQ0Ff
SURFTlRJVFlfREVGQVVMVCkKIAl7CiAJCXJlbGF0aW9uX21hcmtfcmVwbGljYV9pZGVudGl0eShy
ZWwsIHN0bXQtPmlkZW50aXR5X3R5cGUsIEludmFsaWRPaWQsIHRydWUpOwotLSAKMi4zOS41IChB
cHBsZSBHaXQtMTU0KQoK
--000000000000a8ed1706482d22d2--