----- Original Message -----
From: "johnsparrowuk" <jsparrow@...>
Subject: CHECK Constraints (was: Re: [firebird-support] Re: Checking periods don't overlap)
> My point is that check constraints should work in a way consistent
> with indexes, which at the moment they don't.
>
> From testing I can see that a unique index can see uncommitted values
> in another transaction. It can also see committed values that have
> been deleted in another transaction (the point you make). But as soon
> as that other trans commits the delete, I am allowed to insert the
> new record without restarting the other (snapshot) transacton.
>
> It depends on your definition of 'dirty read' I suppose. The jargon
> was developed before multi-gen systems were designed I guess, so
> there could be some confusion.
In fact it was you who seggested dirty-reads:
> > I am only suggesting dirty-read be used for check constraints
thus I expect you should supply its definition.
I simply showed that neither of the only two definitions I can imagine (read last
version/read all versions) will not solve anything, just add more problems.
Even if you add such feature, the next day you will suggest that
"Check constraints should work in a way consistent with application.
Why my application can't restrict data the same way as check constraint ?
Let's make dirty-read transactions the default" :-)