Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error

On Wed, Nov 26, 2025 at 8:27 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Nov 6, 2025 at 7:00 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > Among those options, I considered the following block, which adds a
> > ctid for the partitioned root table when it’s the only target in the
> > query after partition pruning removes all child tables due to the
> > WHERE false condition in the problematic case:
> >
> > /*
> > * Ordinarily, we expect that leaf result relation(s) will have added some
> > * ROWID_VAR Vars to the query. However, it's possible that constraint
> > * exclusion suppressed every leaf relation. The executor will get upset
> > * if the plan has no row identity columns at all, even though it will
> > * certainly process no rows. Handle this edge case by re-opening the top
> > * result relation and adding the row identity columns it would have used,
> > * as preprocess_targetlist() would have done if it weren't marked "inh".
> > * Then re-run build_base_rel_tlists() to ensure that the added columns
> > * get propagated to the relation's reltarget. (This is a bit ugly, but
> > * it seems better to confine the ugliness and extra cycles to this
> > * unusual corner case.)
> > */
> > if (root->row_identity_vars == NIL)
> > {
> > Relation target_relation;
> >
> > target_relation = table_open(target_rte->relid, NoLock);
> > add_row_identity_columns(root, result_relation,
> > target_rte, target_relation);
> > table_close(target_relation, NoLock);
> > build_base_rel_tlists(root, root->processed_tlist);
> > /* There are no ROWID_VAR Vars in this case, so we're done. */
> > return;
> > }
> >
> > If enable_partition_pruning is off, root->row_identity_vars already
> > contains a RowIdentityVarInfo entry for the tableoid Var that was
> > added while processing the foreign-table child partition. Because of
> > that, the if (root->row_identity_vars == NIL) block doesn’t run in
> > this case, so it won’t add any row identity columns such as ctid for
> > the partitioned root table.
> >
> > In theory, we could prevent the planner from adding tableoid in the
> > first place when the child table doesn’t support any row identity
> > column -- or worse, doesn’t support the UPDATE/DELETE/MERGE command at
> > all -- but doing so would require changing the order in which tableoid
> > appears in root->processed_tlist. That would be too invasive for a
> > back-patch.
>
> I’ve implemented this alternative as well -- the version that prevents
> adding tableoid when no other row-identity columns are added for the
> child. That allows to keep root->row_identity_vars empty so the
> dummy-root path can add ctid as intended by the above code block of
> distribute_row_identity_vars().
>
> This provides an alternative approach to compare against the other patch.

Forgot to mention that with this approach, unlike the other patch, the
targetlists are identical whether or not enable_partition_pruning is
on, since in both cases the if (root->row_identity_vars == NIL) block
of distribute_row_identity_vars() executes:

+SET enable_partition_pruning TO off;
+EXPLAIN (COSTS OFF, VERBOSE) DELETE FROM pt WHERE false;
+ QUERY PLAN
+--------------------------------
+ Delete on public.pt
+ -> Result
+ Output: pt.ctid
+ Replaces: Scan on pt
+ One-Time Filter: false
+(5 rows)

+SET enable_partition_pruning TO on;
+EXPLAIN (COSTS OFF, VERBOSE) DELETE FROM pt WHERE false;
+ QUERY PLAN
+--------------------------------
+ Delete on public.pt
+ -> Result
+ Output: ctid
+ Replaces: Scan on pt
+ One-Time Filter: false
+(5 rows)

pt.ctid in the off case vs only ctid in the on case has to do, I
think, with there being more than one entry in the rtable in the
pruning off case.

--
Thanks, Amit Langote