On Thu, 16 Jul 2026 at 07:20, Chao Li <li.evan.chao@gmail.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,
thesequence 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
RETURNINGfor 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
