Re: BUG #17050: cursor with for update + commit in loop

I wrote:
> The only obvious way to fix this is to always save aside the output
> of a cursor query in case we need to persist it later, so that
> PersistHoldablePortal doesn't have to assume that rewinding is safe.
> That would be pretty catastrophic for performance, though, so I doubt
> anybody will be happy with that answer.
> For cursors that aren't marked scrollable, we might be able to say
> that we only save the *rest* of the query output, and then adjust
> the cursor state appropriately for that choice. Seems possibly
> nontrivial though, and there's still the question of what to do
> for scrollable ones.

Actually ... maybe it's not that bad. The nonscrollable case seems
to be quite simple to fix, and as for the scrollable case, maybe
we can just say it's on the user's head that the query produce
stable results. There's already a prohibition on using FOR UPDATE
with SCROLL, and the DECLARE CURSOR reference page has some warnings
about volatile queries with WITH HOLD, which is basically the same
case as we're worried about here.

I think the DECLARE CURSOR page needs some modernization to mention
that cursors in procedures are basically the same as WITH HOLD.
But as far as code changes go, the attached seems sufficient.

regards, tom lane