From: Zsolt Parragi <zsolt.parragi@percona.com>
In-Reply-To: <684DCC2F-5982-4A5D-93F9-BD640B58B4BB@gmail.com>
References: <E74C57FA-1DD0-4C8E-8FB1-538034752592@gmail.com>
 <CACJufxGRkCSqqRwd+3MMVFbosKXHv=Jc+KyGK+NM3YAHN7eu+g@mail.gmail.com>
 <DCE683F9-CEBF-4EDE-81D1-5E59CCD5CF82@gmail.com>
 <cb4a41fd-67e8-47ed-bcff-d0549dce3f02@app.fastmail.com>
 <33E9C4C2-B6A8-4FCC-BEEA-461EA5FB98C8@gmail.com>
 <CACJufxGxY=1mxcNz8-bjp6R+ZoCRE3O7DYt2ZqObv-Le+aMOqw@mail.gmail.com>
 <7F0EA98A-6DBC-436A-8FF4-4A511A05ABE6@gmail.com>
 <CACJufxFwJH5K1jgL1ryckYX8gxp1sfqz_2ypey1sYtWZ5u45oQ@mail.gmail.com>
 <ahgAsvfSt3kbw88l@alvherre.pgsql>
 <7B7172F4-DB02-4259-997B-6AEF5ADF7FCE@gmail.com>
 <CACJufxHbVuY683j3DHEU4LSswo8DTzLJbTvhv2Uj6gqN8pJs7Q@mail.gmail.com>
 <14E223D8-8425-446A-A36C-6B62BC334656@gmail.com>
 <9A3D388C-1DF4-4C43-9AB6-83529A8F48C8@gmail.com>
 <CACJufxGgSKFGWja=JPv3-zq3whON5cESLp7Z5=OsYvZOaRGnGw@mail.gmail.com>
 <E6956B70-35FF-474D-9F53-FC6E1BD8D9C0@gmail.com>
 <CAN4CZFOOhDAWdnY1OXB1wfG_=C4g_dw0gC2HCApz_3F7EFpqJA@mail.gmail.com>
 <92CAD935-5ECE-46D8-B7D7-D8E3C991CC10@gmail.com>
 <CAN4CZFNjnR-7hPBO=v=9h4CdDogUueYoPqpPvR9k3X5Z9-=+TA@mail.gmail.com>
 <684DCC2F-5982-4A5D-93F9-BD640B58B4BB@gmail.com>
MIME-Version: 1.0
Date: Fri, 5 Jun 2026 11:44:51 -0700
Message-ID: 
 <CAN4CZFPkeF+=sk9KxxncuzGb-Q2NsMG4zoUgff-TiHeEdzwU+w@mail.gmail.com>
Subject: Re: Fix bug of CHECK constraint enforceability recursion
To: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFPkeF%2B%3Dsk9KxxncuzGb-Q2NsMG4zoUgff-TiHeEdzwU%2Bw%40mail.gmail.com>
Precedence: bulk

> * It is common for a partitioned table to have thousands of partitions, but I rarely hear of a regular inherited table having thousands of descendants.

Yes, that's why I also wasn't sure if it's needed or not, I can
construct scenarios where alters take a relatively long time, but
those do not seem to be realistic at all... so maybe it's an
acceptable limitation as you said.

> BTW, do you have any comments on the doc changes in 0002 and 0003?

+   (check and not-null constraints) down the inheritance hierarchy.  With
+   multiple inheritance, if a column or constraint is inherited from more
+   than one parent, the stricter definition applies.

The documentation changes generally look good to me, but should this
statement be part of the alter table description? There's a paragraph
about merge rules above which might be a better fit for it.
("Inheritable check constraints and not-null constraints are merged in
a similar fashion")