From: Zsolt Parragi <zsolt.parragi@percona.com>
In-Reply-To: <92CAD935-5ECE-46D8-B7D7-D8E3C991CC10@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>
MIME-Version: 1.0
Date: Thu, 4 Jun 2026 12:08:02 -0700
Message-ID: 
 <CAN4CZFNjnR-7hPBO=v=9h4CdDogUueYoPqpPvR9k3X5Z9-=+TA@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/CAN4CZFNjnR-7hPBO%3Dv%3D9h4CdDogUueYoPqpPvR9k3X5Z9-%3D%2BTA%40mail.gmail.com>
Precedence: bulk

The new version looks correct, I don't see any logic problem with it,
however, I do have a performance question:

+				/*
+				 * A parent listed in changing_conids is being changed by the
+				 * same ALTER, but it may not have been updated yet.  For
+				 * regular inheritance, recurse upward to check whether an
+				 * equivalent enforced parent outside the ALTER will make it
+				 * remain enforced.  Partitions cannot have multiple parents,
+				 * so they do not need this check.
+				 */
+				if (!rel->rd_rel->relispartition &&
+					list_member_oid(changing_conids, parentcon->oid))

Shouldn't the parent lookup use some form of caching? Otherwise we'll
end up reevaluating the same parents multiple times. I'm not sure if
it is needed or not, how much of a performance impact this can have in
a real-world server.