Re: Fix RETURNING side effects for FOR PORTION OF leftover rows

On Thu, 16 Jul 2026 at 07:20, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> Dean raised a comment on my patch [1] about RETURNING processing for UPDATE ... FOR PORTION OF. While addressing that comment, I found a new problem: UPDATE/DELETE ... FOR PORTION OF currently processes RETURNING for leftover rows as well, which seems wrong because it can cause unexpected side effects.
>
> Here is a simple repro using a sequence:
>
> The UPDATE FOR PORTION OF command generates two leftover rows, and both cause RETURNING to be processed. As a result, the sequence is advanced three times, which seems unexpected from the user's perspective.

Yes, I wondered whether that could happen. We should definitely fix
this. Apart from anything else, it's not good that it can execute
user-defined functions on the leftover rows, which haven't been
checked against RLS SELECT policies.

> To fix the problem, since leftover rows are inserted by calling ExecInsert(), and ExecInsert() is a local static function, I think a simple and safe solution is to add a new parameter to ExecInsert() to indicate whether to process RETURNING for this insert. Then UPDATE/DELETE FOR PORTION OF can bypass RETURNING processing for leftover rows.

I don't particularly like adding another argument to ExecInsert(). I
think it can work out from its existing arguments whether it's part of
a FOR PORTION OF query (by looking at mtstate).

Regards,
Dean