locking" will probably not work with
> PostgreSQL: since any change in a data row will cause a new row to be
> created, there would be no advantage.
I didn't think of that. I can certainly see that
update-by-tuple-duplication makes it difficult to implement this case
"opti
by a standard?
(2) "cell"-level beinginefficient?
(3) no one having implemented "cell"-level locking?
(4) there being a problem with having a DELETE correctly
conflict with a "cell"-level lock?
(*) something else?
In short, I am wondering whether this behavior is
