Commented by: Nikolay Ponomarenko (pnv82)

Seem's it could be useful for custom replication engines

Commented by: Sean Leyne (seanleyne)

Nikolay,

I was thinking the same thing, but given that the replication engine would have to check the Oldest Active Transaction value in order to use the version transaction number, I don't see what value the pseudocolumn would bring.

Further, given that there could be hundreds of versions for a record and that a connection can not set a specific transaction number there would be no way to perform a full sync.

Commented by: @aafemt

For replication AFAIU this column is useless. I rather think about cumulative backup: select * from t where RDB$TRANSACTION_ID>2.
Internally the engine could use this column, for example, to control versioned metadata cache.

Commented by: @dyemanov

If some record has been modified by the current transaction, this pseudo-column would return the current transaction ID rather than the ID of the transaction the committed record version belong to. Is it acceptable?

Commented by: @aafemt

Of course it is. In this way the value is even more useful.

Commented by: @hvlad

I'm not against this feature just want to add that it is impossible to create consistent view of database ("cumulative backup") using just this new pseudo-column.