On Thu, 16 Jul 2026 at 07:20, Chao Li <[email protected]> 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
