[EMAIL PROTECTED] writes:
> If I understand correctly, and I've sort of just worked on this
> assumption, a sequence does not nessisarily produce a sequence of numbers.
> It produces a succession of numbers that are guarenteed to increase, but
> not nessisarily with a specific interval (usually one).
It produces a series of numbers that are guaranteed to be *different*.
The always-increasing property is valid as far as the numbers delivered
in a single session go, but it doesn't hold across backends, so I think
the extent to which you can rely on it is pretty limited.
> The "addval" is similar, you can add a value to a sequence. It should be
> OK, but is not guarented to be MVCC. The admin or developer will have to
> correct any rollbacks.
This strikes me as a complete nonstarter. How would a failed
transaction fix anything, or even tell anyone else that there was now
something needing to be fixed? You'd have to rely on the client to
start a fresh transaction and do the fixup. In practice the total would
get out of sync in no time.
Also, I don't see how you would actually use this without needing addval
to accept negative increments (for decrementing totals on delete, etc).
That seems to create a whole new set of semantic issues, because now you
no longer have the "it's the same as N consecutive nextval's" rule to
define the behavior for you.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
