> That is also the safe thing to do, since PostgreSQL's implementation
> WITH HOLD cursors doesn't leave the rows locked. That can lead to the
> rows being deleted from under the cursor, for which the standard is
> unclear as to whether that is acceptable, or not.

Um, the default use case is to "intent exclusive" lock the current row,
so you can do some calculations on columns inside the application
them changing in the meantime. 
So, imho that lock is a substantial feature of FOR UPDATE cursors.
The lock is usually freed as soon as you fetch the next row.
In MVCC db's it is also a method to read a guaranteed up to date


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to