On Fri, 7 Nov 2025 at 11:02, Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Thu, Nov 6, 2025 at 7:00 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > I looked at a few options, but none seem non-invasive enough for
> > back-patching, apart from the first patch I posted. That one makes
> > ExecInitModifyTable() not require a ctid to be present to set the root
> > partitioned table’s ri_RowIdAttNo, except in the case of MERGE, which
> > seems to need it. The corner case that triggers the internal error for
> > UPDATE/DELETE doesn’t occur for MERGE now and likely won’t when
> > foreign tables eventually gain MERGE support; don't mark my words
> > though ;-).
>
> Well, OK, I just had not tried hard enough to see that the same error
> happens for MERGE too.
>
> With my patch applied:
> EXPLAIN VERBOSE MERGE INTO pt t USING (VALUES (1, 'x'::text)) AS s(a,
> b) ON false WHEN MATCHED THEN UPDATE SET b = s.b;
> ERROR: could not find junk ctid column
>
> I have another idea: we can simply recognize the corner condition that
> throws this error in ExecInitModifyTable() by checking if
> ModifyTable.resultRelations contains only the root partitioned table.
> That can only happen for UPDATE, DELETE, or MERGE when all child
> relations were excluded.
>
> Patch doing that attached. Added test cases to file_fdw's suite.
>
> --
> Thanks, Amit Langote
HI!
I think this is an OK option for backpatching. After v2 applied, I
found the behavior of DELETE and EXPLAIN DELETE consistent. The only
remaining issue is VERBOSE output difference with or without
enable_partition_pruning (which is v19+ issue to worry about),
correct?
Also, should we add COSTS OFF to EXPLAIN in the regression test? I
understand that costs should be always zero, but COSTS OFF is almost
everywhere is tests
--
Best regards,
Kirill Reshke
