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 tuple deformation with virtual generated NOT NULL columns
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAApHDvqrPnvJcTCT6631OHwMbXmP66uOmhrc7-0KG_8kwJ3wPA@mail.gmail.com>
Date: Thu, 18 Jun 2026 13:55:58 +0800
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 Peter Eisentraut <peter@eisentraut.org>,
 Andres Freund <andres@anarazel.de>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <03C47613-5C89-4E69-BB72-3B2912BDDDA8@gmail.com>
References: <A4BC563C-0CA3-4EF3-952A-EA41F9E5BF1E@gmail.com>
 <CAApHDvoQKY8zHb1LZBuYZBRszi0qVmTaV_zFup=A9xqRpJWMRQ@mail.gmail.com>
 <pse3eru75b5skbvc7jjrf7origavqojc6nqtwdrr7z6sjkyxfo@siklvj643v4f>
 <BB69B882-5401-45CE-919E-8A78511EDABC@gmail.com>
 <CAApHDvogTSD_G1nkJqOvO3gZFACQUCbKg6U7yBB48r5RMaR7-Q@mail.gmail.com>
 <CAApHDvrJBXEhet4=Es_wHBKdv5PCV5OGCaJOSmJexeaFqfmUHA@mail.gmail.com>
 <1151393.1781734980@sss.pgh.pa.us> <1174236.1781736349@sss.pgh.pa.us>
 <CAApHDvpE1Jx=NrwUCihrfP+Dmkfn6kUkpCZYC10Yo+wkMu3ssQ@mail.gmail.com>
 <CAApHDvq6FaC441C=G4Q9fNZQ-OKmaeW8yP0YjHpjyjBeWhj3+g@mail.gmail.com>
 <2A622929-A45C-4370-943A-BC76FF4CC433@gmail.com>
 <CAApHDvqrPnvJcTCT6631OHwMbXmP66uOmhrc7-0KG_8kwJ3wPA@mail.gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/03C47613-5C89-4E69-BB72-3B2912BDDDA8%40gmail.com>
Precedence: bulk


> On Jun 18, 2026, at 13:18, David Rowley <dgrowleyml@gmail.com> wrote:
>=20
> On Thu, 18 Jun 2026 at 14:36, Chao Li <li.evan.chao@gmail.com> wrote:
>> I tested the fix, and it seems to work. While tracing the code, I =
wondered about this part:
>> ```
>> -               if (att->attnullability =3D=3D ATTNULLABLE_VALID &&
>> -                       !att->atthasmissing &&
>> -                       !att->attisdropped)
>> +               if (attr->attgenerated =3D=3D =
ATTRIBUTE_GENERATED_VIRTUAL)
>> +                       break;
>> +
>> +               if (catt->attnullability =3D=3D ATTNULLABLE_VALID &&
>> +                       !catt->atthasmissing &&
>> +                       !catt->attisdropped)
>>                        guaranteed_column_number =3D attnum;
>> ```
>>=20
>> When computing guaranteed_column_number, I think we can just skip the =
virtual generated column rather than break. Using the test from Tom=E2=80=99=
s email:
>=20
> Yeah, I was confused at first as I'd done a similar optimisation in
> the non-JIT deform code, but there "guaranteed" means guaranteed to be
> present in the tuple data, whereas with the JIT code it means
> guaranteed in the tuple data or its NULL bitmap.
>=20
> I've attached v2 which includes a test that exercises deforming with
> tuples which have various natts counts. I propose to backpatch
> 1f7dfe8c8 to v18 before applying the attached to master and v18.
>=20
> David
> <fix_jit_deform_for_virtual_generated_cols_v2.patch>

This version looks good to me. Only a small comment:

```
+-- try adding a virtual generated column to an existing table with =
tuples,
+-- then try adding an atthasmissing column before adding a normal =
nullable
+-- column.
+--CREATE TABLE gtest21d (a int NOT NULL);
+--INSERT INTO gtest21d (a) VALUES(10);
+--ALTER TABLE gtest21d ADD COLUMN b INT GENERATED ALWAYS AS (a * 10) =
VIRTUAL NOT NULL;
+--SELECT * FROM gtest21c ORDER BY a;
+--INSERT INTO gtest21d (a) VALUES(20);
+--ALTER TABLE gtest21d ADD COLUMN c INT NOT NULL DEFAULT 1234;
+--SELECT * FROM gtest21c ORDER BY a;
+--ALTER TABLE gtest21d ADD COLUMN d INT;
+--INSERT INTO gtest21d (a, c, d) VALUES(30, 12345, 100);
+--SELECT * FROM gtest21c ORDER BY a;
+--DROP TABLE gtest21d;
```

I don=E2=80=99t know why you added these commented SQL statements, I =
guess you have your reason. The problem is, in the 3 SELECTs, gtest21c =
should probably be gtest21d.

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