hi all
Вот DDL, с совершенно идиоцким check'ом:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
recreate table foo(id int primary key);
commit;
set term ^;
execute block as
begin
execute statement 'drop sequence g'; when any do begin end
end
^ set term ;^
commit;
create sequence g;
commit;
insert into foo values(1);
insert into foo values(2);
insert into foo values(3);
commit;
alter table foo add constraint foo_bar
check(
exists(select * from foo x where gen_id(g,1) >= 0 and x.id > 0 and x.id <> foo.id )
);
set count on;
set echo on;
update foo set id = -id; -- должен обломаться или нет ?
set count off;
select * from foo;
select gen_id(g, 0) from rdb$database;
На 2.5 он выдаст:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
update foo set id = -id;
Records affected: 3
set count off;
select * from foo;
ID
============
-1
-2
-3
select gen_id(g, 0) from rdb$database;
GEN_ID
=====================
3
На 3.0:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
update foo set id = -id;
Records affected: 3
set count off;
select * from foo;
ID
============
-1
-2
-3
select gen_id(g, 0) from rdb$database;
GEN_ID
=====================
6
Судя по значению gen_id, встроенный check-триггер на update точно отрабатывал. То, что в 3.0 он это делал большее число раз - хрен с ним. То, что в 3.0 он позволил выполниться апдейту - ну, наверное, так и должно быть: курсор не должен видеть свои собственные изменения, пока работает.
Но почему он прокатил в 2.5, в котором стабильности этой нету и курсор должен был на этапе удаления id = 3 увидеть свои изменения и, след-но, exists() в этот момент должен был вернуть false - ?
