Hi All.

I tried to discuss this in fb-devel, but seems there is not proper
time to bother developers who is busy with realease.
Let's compare behaviour of update in mentioned mode for popular
RDBMS:

1. Application 1 starts transaction and updates some record
2. Application 2 starts read_commited rec_version wait
transaction (for Oracle and MSSQL - read commited transaction and
wait statement), tries to update the same record and waits.
3. Application 1 commits. Application 2:

IB/FB Oracle MSSQL
exception perform update perform update
update conflicts and ready to and ready to
with concurrent commit commit
update

note in read_commited no_rec_version wait FB behaviour is the same as
Oracle and MSSQL, but this mode is very inconvinient for selects
within the same transaction.

Questions:
1. Can someone here to check behaviour of most close to us server -
PostgreSQL (nor me, neither anyone of my friends are not familiar with
it to be shure we don't miss some option etc)?

2. Our transaction waited seeing uncommited changes. Well, in some
moment this changes became commited. Why conflict is registered? Since
this moment data is updatable in accordance to definition of
read_commited isolation level. I predict contradiction - we wanted to
update one version of record but when our concurrent`s changes were
commited this is another version and our changes can be incorrect. But
if we make update like Set a=b and our intention is based on previous
state of this record, in read_commited this state can be outdated just
after our read and we successfully will make wrong update. To be shure
in correctness of such updates we should use concurrency isolation
level and read data to be updated in this transaction's context. Is it
sensible to play with nanoseconds in time of update itself? IMO in
read_commited wait reasonable person will make only incremental
updates like Set a=a+b, and if FB behaviour will be the same as
another servers, this will simplify design of such applications and
portation of applications between servers.

3. If I'm not wrong above, what evil is less - change behaviour and
perhaps break some existing application based on it, or leave it as is
and sacrifice portability and simplicity of design of some particular
applications which requires conflictless incremental updates, loosing
some part of potential newcomers from Oracle and MSSQL?

Best regards,
Alexander.