> From: "Ann W. Harrison" <aharrison@...>
> >According to the quote from Ann (peace be upon her, grin) she also
> >believes check constraints should operate in the system transaction
> >(is my jargon right? Basically exhibit consistent behaviour with
> >indexes, yeah?)
>
> Right. And they don't. And they should. And it won't be
> trivial to make them work. Damn!

Ann, John,

Still nobody explained what "operate in system transaction" or
"operate in system context" or "dirty read" or "potato" means in the context
of this discussion, nor tried to list advantages/disadvantages/consequences of it.

Does it mean "read values from last record version, even if it is uncommitted" ?
Yes or no ?

If yes then here is what will happen in such case when running slightly
changed example from "[ firebird-Bugs-973159 ] Check constraints don't operate in system context":

----------
ALTER TABLE T ADD CONSTRAINT Unique_I_T CHECK
(not exists (select pk from T where new.i = T.i and pk <> new.pk)

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

Trans 1:
ROLLBACK ... since no constraints are re-checked during Rollback,
the unwanted (1,1) value will happily creaps-in, despite running
in "system context". What am I missing ?

Start new trans:
select * from T
1,1
2,2
3,1 (violation of check constraint) !!!

----------
Ivan