On one hand, I'm inclined to agree with you, maintaining state for a rolled
back transaction makes sense. But by trying to track sequence values by
transaction and reusing rolled back values, you destroy the advantages of
using a sequence in the first place, as well as making things far, far more
complicated in the long run.
For example, you have two transactions, A and B. B is committed while A is
rolled back. If you grab the sequence values when the queries are executed,
A had a value of 1 and B used the value of 2. So the sequence should issue a
nextval of 3. But A was rolled back. Does this mean that the sequence now
has to track every value in use? Alternately, if the values are assigned
when the transaction is committed, you have the problems of an undefined
value during the transaction. How can you perform integrity checks on an
undefined value?
The idea of a database returning to a different state upset me at first. But
after some thought and consideration, I realized that there really is no
better way to handle it, other than creating your own, far slower, far more
complicated system. Because you have several potential concurrent processes
reading and writing to a single value, you just can't expect to return that
value to its original state.
Greg
> Its not that I care about holes, but if roll back mean to return the DB to
> its original status because a foul sql chain command then logically I
expect
> that everything will roll back like the action was never accorded
>
> > Why do people care about holes anyway? I've never understood that...
