Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: [PATCH] Rebuild CHECK constraints after generated column SET
 EXPRESSION
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CACJufxFG+vn8vdHAedGuqwb9iC58HHPGSEaLwm6_Tcv-3AyH=w@mail.gmail.com>
Date: Wed, 10 Jun 2026 17:15:38 +0800
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 pgsql-hackers@lists.postgresql.org,
 Peter Eisentraut <peter@eisentraut.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B8C04AD-B4F1-43E3-8BC3-7A8800F3498B@gmail.com>
References: 
 <CAJTYsWXOkyeDVbzymWc9sKrq7Y_MUv6XJXN4H9GfsBOPd3NJ+w@mail.gmail.com>
 <CACJufxE3e1jPsKLsjNWMucahFJW7UO_UGWzhRESRvJ+8PeKgkg@mail.gmail.com>
 <CAJTYsWX+g49jMArk0MdS0+suEY8CckyAYpm+KvNLU9Zx9=6t3g@mail.gmail.com>
 <CACJufxGPNgAcQEiwD0QFCTP8vi0XZzys06EEQUnR84_0Qo9s9Q@mail.gmail.com>
 <CAJTYsWUooEDFaNOiOLjz0NqmqBtof65b-sQQHWmh8jV9t-VYEA@mail.gmail.com>
 <CACJufxGBSeAcyStRHajNvqerGCRGB5Wb=e5cbGd7HFT4=aMsLw@mail.gmail.com>
 <CAJTYsWWw7s0N2hnAW9pfhkSx-aN=wELErrBEicoPMnmmS1e7kg@mail.gmail.com>
 <CACJufxGdr-A7hwBRWh02YHbb13M-LG3bAOad+86iivp2008tTA@mail.gmail.com>
 <CAN4CZFMHmb=o_GkJrgEY1iEQpnuDtL_YEHKFZNWG0bdZyozXvA@mail.gmail.com>
 <CACJufxFG+vn8vdHAedGuqwb9iC58HHPGSEaLwm6_Tcv-3AyH=w@mail.gmail.com>
To: jian he <jian.universality@gmail.com>,
 Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/4B8C04AD-B4F1-43E3-8BC3-7A8800F3498B%40gmail.com>
Precedence: bulk


> On Jun 2, 2026, at 08:41, jian he <jian.universality@gmail.com> wrote:
>=20
> On Fri, May 29, 2026 at 6:58=E2=80=AFAM Zsolt Parragi =
<zsolt.parragi@percona.com> wrote:
>>=20
>> Looks good, I have one nitpick question:
>>=20
>> +                       if (isnull)
>> +                               elog(WARNING, "null conbin for =
relation \"%s\"",
>> +                                        =
RelationGetRelationName(rel));
>>=20
>> Shouldn't this be an error instead? Most existing checks treat it as
>> an error, and that seems better to me as this shouldn't happen
>> normally?
>>=20
> OK.
>=20
> I changed it to:
>> +                       if (isnull)
>> +                               elog(ERROR, "null conbin for relation =
\"%s\"",
>> +                                        =
RelationGetRelationName(rel));
>=20
> I also slightly rephrased the commit message.
>=20
>=20
>=20
> --
> jian
> https://www.enterprisedb.com/

Sorry for not noticing this thread earlier. I also found the same =
problem while testing the feature and posted a patch in [1]. Thanks to =
Jian for pointing out this thread.

After reading v6 from this thread, I think my implementation is slightly =
different:

* v6 adds a new helper, RememberWholeRowDependentForRebuilding(), which =
reads pg_constraint and pg_index to find objects to rebuild.
* My implementation in [1] reuses RememberAllDependentForRebuilding(), =
which reads pg_depend, because whole-row dependencies have refobjsubid =3D=
 0. My v1 missed the partial-index case, so I added a new helper in v2 =
to read pg_index.

The main difference is that my patch reuses the existing =
dependency-based rebuild machinery where possible, and only scans =
pg_index directly for the partial-index case where pg_depend does not =
record the whole-row Var dependency. It is also smaller: this thread=E2=80=
=99s v6 adds 185 lines to tablecmds.c, while my v2 adds 123 lines.

Would you mind taking a look at my implementation in [1]?

BTW, I have also added this problem to the open items list, as I think =
it should be fixed before releasing v19.

[1] =
https://www.postgresql.org/message-id/71242FEA-15A3-4073-9FA1-561CA744ACBD=
%40gmail.com

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