So let's say you start a transaction by grabbing t# 1000 and 1001.

You start your insert-from-select (would be infinite) and tell it to -only- see records that would
have existed as of 1000, and ignore 1001 records. It inserts all new records as 1001. (Generalize
this to insert/update/delete changes.)

Now you start a second statement doing something similar, in the same transaction. But you're still
using 1000 and 1001. Now what?

You'd have to grab a new transaction number for every statement, not just two, effectively using it
as a compound key. How this might affect savepoints is beyond me, but I have a strange feeling it'd
go badly. Plus, it messes with the transaction < transaction math. As you can't know how many
transaction numbers to reserve, you'd have to take them off the generator, which means each
transaction could use transaction numbers greater than the beginning transaction number inside
another concurrent transaction that shouldn't be able to see the changes -- which is a bad thing.
I'm rather fond of transaction isolation, myself.

-Philip

---------- Original Message -----------
From: Alexander Klenin <klenin@...>

> Perhaps there is some merit to the idea of using several transaction
> numbers per transaction?
> Numbers are cheap, just increase the counter by 2 instead of 1.
> Then you can sub-allocate these numbers to different statement "stages".

------- End of Original Message -------