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: 
 <CAApHDvoQKY8zHb1LZBuYZBRszi0qVmTaV_zFup=A9xqRpJWMRQ@mail.gmail.com>
Date: Sun, 7 Jun 2026 09:43:34 +0800
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <981D66D0-1185-4319-9C32-9317966C8A02@gmail.com>
References: <A4BC563C-0CA3-4EF3-952A-EA41F9E5BF1E@gmail.com>
 <CAApHDvoQKY8zHb1LZBuYZBRszi0qVmTaV_zFup=A9xqRpJWMRQ@mail.gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/981D66D0-1185-4319-9C32-9317966C8A02%40gmail.com>
Precedence: bulk


> On Jun 6, 2026, at 12:50, David Rowley <dgrowleyml@gmail.com> wrote:
>=20
> On Thu, 4 Jun 2026 at 17:57, Chao Li <li.evan.chao@gmail.com> wrote:
>> While testing "Optimize tuple deformation=E2=80=9D, I found a bug:
>=20
>> I think the problem is in finding the first non-guaranteed attribute =
where virtual generated attributes are not considered:
>=20
> Thanks for the report and fix. I pushed a slightly adjusted version.

Thanks for pushing.

> Form_pg_attribute.attgenerated is '\0' for non-generated columns, so
> there's no point in checking cattr->attgenerated as well as that.
>=20

I was trying to avoid unconditionally fetching TupleDescAttr(tupdesc, =
i), since cattr->attgenerated is already available and most columns =
won't be virtual generated columns. But I was probably overthinking the =
performance angle here. TupleDescFinalize() runs only when finalizing a =
tuple descriptor, not during per-tuple deformation. I agree your =
adjusted version is cleaner.

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