On Fri, Feb 09, 2007 at 11:21:59AM -0500, Tom Lane wrote:
>
> Usually the best approach is to fetch the data without acquiring any
> lock, allow the interactive editing to happen outside a transaction,
> then when the user hits SAVE, perform a transaction that locks the
> row(s), checks for conflicting changes, and commits if no conflict.
Might you please expand on how the application could check for
conflicting changes? Would this be simply fetching the record
again, and comparing to the previously-fetched version, to see
if the record is still as it was when the user started editing?
Something more sophisticated?
Thank you for your time.
Jim
