Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: Fix SET EXPRESSION for virtual columns with whole-row
 dependencies
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CACJufxHTK0Qk7AwdrHK=y8OtK--zEVY-Ossxx4UUgxaE2NCAXA@mail.gmail.com>
Date: Tue, 9 Jun 2026 15:28:18 +0800
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
 Peter Eisentraut <peter@eisentraut.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B739323-C897-4B1A-9BFC-656E5CB4AD58@gmail.com>
References: <71242FEA-15A3-4073-9FA1-561CA744ACBD@gmail.com>
 <CACJufxHTK0Qk7AwdrHK=y8OtK--zEVY-Ossxx4UUgxaE2NCAXA@mail.gmail.com>
To: jian he <jian.universality@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/5B739323-C897-4B1A-9BFC-656E5CB4AD58%40gmail.com>
Precedence: bulk


> On Jun 9, 2026, at 15:23, jian he <jian.universality@gmail.com> wrote:
>=20
> On Tue, Jun 9, 2026 at 2:23=E2=80=AFPM Chao Li =
<li.evan.chao@gmail.com> wrote:
>>=20
>> Hi,
>>=20
>> While testing =E2=80=9C[f80bedd52] Allow ALTER COLUMN SET EXPRESSION =
on virtual columns=E2=80=9D, I found that the feature missed handling =
whole-row check constraints.
>>=20
>> Here is a repro:
>> ```
>> evantest=3D# create table t(
>> evantest(#   a int,
>> evantest(#   b int generated always as (a*2) virtual,
>> evantest(#   constraint row_c check (t is not null)
>> evantest(# );
>> CREATE TABLE
>> evantest=3D# insert into t(a) values(1);
>> INSERT 0 1
>> evantest=3D# alter table t alter b set expression as (nullif(a, 1));
>> ALTER TABLE
>> evantest=3D# select * from t;
>> a | b
>> ---+---
>> 1 |
>> (1 row)
>> ```
>>=20
>> The ALTER TABLE should fail, because it makes b become NULL, which =
breaks the constraint row_c.
>>=20
>=20
> Hi.
>=20
> In case you are wondering whole-row objects:
> ALTER TABLE DROP COLUMN and ALTER COLUMN SET DATA TYPE are covered by
> https://commitfest.postgresql.org/patch/5988 and
> https://commitfest.postgresql.org/patch/6055.
>=20
> Meanwhile, ALTER TABLE SET EXPRESSION is being handled over in
> https://commitfest.postgresql.org/patch/6755

Thanks for pointing out that. I will review 6755.

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