Tom, thanks ! You are even helping lurkers like me that haven't asked anything :-)
... > A better design is to fetch the data without locking it, allow the > user to edit as he sees fit, and then when he clicks "save" you do > something like > > begin; > select row for update; > if [ row has not changed since you originally pulled it ] then > update row with changed values; > commit; > else > abort; > notify user of conflicts > let user edit new data to resolve conflicts and try again > fi > > In this design the row lock is only held for milliseconds. > > You need to provide some code to let the user merge what he did with the > prior changes, so that he doesn't have to start over from scratch in the > failure case. > BTW, a handy proxy for "row has not changed" is to see if its XMIN > system column is still the same as before. If so, no transaction has > committed an update to it. (This may or may not help much, since you're > probably going to end up groveling over all the fields anyway in the > "notify user" part, but it's a cool hack if you can use it.) Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
