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 bug of UPDATE/DELETE FOR PORTION OF with inheritance tables
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CA+renyXQYOU6hRymFOd26fkvVLNmdFvvMsAzsaJUOCsKveLUQw@mail.gmail.com>
Date: Wed, 27 May 2026 15:55:38 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 jian he <jian.universality@gmail.com>,
 Peter Eisentraut <peter@eisentraut.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E0A0FF4-3E57-415E-A1C7-F1184F1EDC32@gmail.com>
References: <4245F94D-84F1-4E05-BF81-C458A6CF9901@gmail.com>
 <260A544F-FBD6-40CC-9449-5987049DD2D4@gmail.com>
 <CA+renyV6BS+cUxAbxB1X-bBn8+9NDEwRah8pSD_EVdhtb1TcUA@mail.gmail.com>
 <A6C9443A-1F61-4172-8A9A-5ECED30AB8BF@gmail.com>
 <CA+renyVNmXityjqZNdKhG2SGkfKFM1dT72PTbkyQ5K6L9m9NuQ@mail.gmail.com>
 <CA+renyXQYOU6hRymFOd26fkvVLNmdFvvMsAzsaJUOCsKveLUQw@mail.gmail.com>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Archived-At: 
 <https://www.postgresql.org/message-id/5E0A0FF4-3E57-415E-A1C7-F1184F1EDC32%40gmail.com>
Precedence: bulk


> On May 27, 2026, at 09:28, Paul A Jungwirth =
<pj@illuminatedcomputing.com> wrote:
>=20
> On Tue, May 26, 2026 at 9:14=E2=80=AFAM Paul A Jungwirth
> <pj@illuminatedcomputing.com> wrote:
>>=20
>> I thought the ExecInitForPortionOf refactoring was still nice to =
keep,
>> and it seemed to fit better here. (I should have updated the commit
>> message not to mention UPDATE OF though.)
>=20
> I looked at the original v1 patch again. I thought the commit message
> was excellent, so I pulled that into the latest patch, also some
> comment changes and the partitionRouting boolean and some test
> double-checks. I still like how ExecInitForPortionOf cuts down on the
> branchiness and the variables used to track attnums, and also how it
> gathers a lot of the child table setup in one place. The v1 seemed
> hard to trace all the cases from top to bottom. For instance it
> initialized map for all child tables, but then only used it for
> partitions.
>=20
>> But thinking about it this morning, I realized: the planner already
>> prunes partitions before we get here. Lazily initializing the structs
>> is trying too hard. Is there some scenario where that actually saves
>> work?
>=20
> Never mind, of course you can filter rows (and whole tables) besides
> just by partition pruning/constraint exclusion.
>=20
> I'm not sure whom to list as author/co-author/reviewer for this patch,
> but I took a stab at it. I think most of the current code is from jian
> he's version, but all three of us have contributed a lot by this
> point.
>=20
> Yours,
>=20
> --=20
> Paul              ~{:-)
> pj@illuminatedcomputing.com

Hi Paul,

I just tested v3 with my original repro, and it has resolved the bug I =
reported.
```
evantest=3D# create table p (id int, valid_at daterange, name text);
CREATE TABLE
evantest=3D# create table c (extra text) inherits (p);
CREATE TABLE
evantest=3D# insert into c values (1, daterange('2000-01-01', =
'2010-01-01'), 'old', 'x');
INSERT 0 1
evantest=3D# update p for portion of valid_at from '2001-01-01' to =
'2002-01-01' set name =3D 'new' where id =3D 1;
UPDATE 1
evantest=3D# select * from only p;
 id | valid_at | name
----+----------+------
(0 rows)
evantest=3D# select * from c;
 id |        valid_at         | name | extra
----+-------------------------+------+-------
  1 | [2001-01-01,2002-01-01) | new  | x
  1 | [2000-01-01,2001-01-01) | old  | x
  1 | [2002-01-01,2010-01-01) | old  | x
(3 rows)
```

I also noticed that the =E2=80=9CUPDATE OF=E2=80=9D related information =
has been removed from the commit message. I can still reproduce the =
UPDATE OF issue with v3, but I think that is expected, and that issue =
will be resolved by the other patch.

So v3 looks clean and good to me. Thanks for updating the patch and =
making the two patches decoupled.

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