You are talking about optimistic locking, commonly used for web applications where there is no transaction kept open during user think time.
Yes, I said as much a couple of emails ago.
And more importantly it is very important that people do not use a SELECT without a FOR UPDATE and introduce subtle, unreproducible threading errors.
Ok. This does get covered, though I agreed earlier that there seems to be room for improvement.
So please do have the update (or similar) inserted. If you wanted to also talk about optimistic locking that would be fine, but probably not necessary.
Just to be clear - this isn't going to be up to me (at least, not anytime soon). First a correctly written patch needs to be produced. If/when someone decides to do that we can move onto getting it applied to the source code (which is done by a committer, which also is not me).
P.S. Do you know if Postgresql Guarantees that all timestamps are distinct, even if they occur within the same clock tick? (i.e. does it run the clock forward). I have another reason to know that. Using clocks is iffy for synchronization.
I've never seen such a guarantee documented...but the details involved are beyond my experience with the code.
David J.
--
Anthony@Berglas.org
+61 4 4838 8874
Just because it is possible to push twigs along the ground with ones nose does not necessarily mean that that is the best way to collect firewood.
