On Wed, 12 Mar 2025 at 16:11, Tender Wang <tndrwang@gmail.com> wrote: > > I can find another same error in the below query: > > with t as (update part_abc set c = true where a = stable_one() +2 returning a) insert into foo select a from t; >
Interesting example. That passes in HEAD, but fails with the v1 patch because it is attempting to open a pruned result relation when it doesn't need to.
Attached is a rough patch that attempts to solve these issues locally in ExecInitModifyTable(), by not allowing all result relations to be pruned for that node. That makes it easy to handle cases with multiple ModifyTable nodes.
This also has the advantage that all these relations can continue to be pruned from the subplans of the ModifyTable nodes, making those scans more efficient, and it only keeps a pruned result relation if all other result relations have been pruned.
It does mean that ExecGetRangeTableRelation() needs to allow pruned relations to be opened, if called from ExecInitResultRelation(). I think that's OK because the check for opening pruned relations still applies to scan relations.
I also adjusted explain.c slightly, to avoid the dummy pruned result relation that we might now keep from appearing in the EXPLAIN output as a target relation. Allowing it to be shown looked a bit odd, because it's not really the target relation in any real sense.
I also noticed a few Asserts in ExecInitModifyTable() that didn't appear to be doing what they were originally intended to do.
I tested and debugged the attached patch. I didn't find any other issue.
A comment in execPartition.h may need to be changed:
* partrel Partitioned table Relation; obtained by * ExecGetRangeTableRelation(estate, rti), where
Because the func interface has changed, the above comments are better to be changed "ExecGetRangeTableRelation(estate, rti, false)".
