--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@s...> wrote:

> Trans 0:
> insert into T values (1,1); WORKS FINE
> commit;
>
> Trans 1:
> update T set i=5; WORKS FINE
>
> Trans 2:
> insert into T values (2,2); WORKS FINE
> insert into T values (3,2); CHECK VIOL, COOL!
> insert into T values (3,1); WORKS FINE !!! Anybody disagree ?
> commit

Errrm, I disagree! What would happen if this was a unique index? (I
cheated and tried it):

After the update in trans 1, you can't insert (3,1) or (3,5) into
the table. Both are blocked.

I guess the system context sees both the committed (1,1) and the
uncommitted (1,5)?

(That's kind of interesting. Because if trans 1 commits then you
*can* insert 1,5. What you can and cant do changes inside a snapshot
trans, which seems a bit of a Isolation violation to me... maybe
unique index checking should be deferred until commit too?? grin,
guess that wouldn't be practical)

Ivan, I don't doubt there's loads of heavy technical problems
associated with getting this to work. Maybe the DEFERRED constraint
thing is a easier idea?

I just want unique constraints to *work* (or, more specifically,
time overlap constraints). If they don't then it's a big
deficiency...

And they sure don't work properly at the moment.

John