[MDEV-23340] Incomplete condition is checked when updating a view defined using WITH CHECK OPTION clause Created: 2020-07-30  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Views
Affects Version/s: 10.1.45, 10.2.32, 10.3.23, 10.4.13, 10.5.3
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Igor Babaev Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-23336 CHECK OPTION is ignored for a multi-t... Confirmed

 Description   

The following test case demonstrate the problem:

create table t1 (a int) engine=myisam;
create table t2 (a int) engine=myisam;
create table t3 (a int) engine=myisam;
create table t4 (a int) engine=myisam;
insert into t1 values (0), (3), (1);
insert into t2 values (1), (0);
insert into t3 values (7), (3), (1);
insert into t4 values (3), (8), (7), (1);
create view v1 as select t1.a from (t1 join t2 on t1.a>t2.a) join (t3 join t4 on t4.a > t3.a) on t1.a<t4.a with check option;
update v1 set v1.a=9 where v1.a=1;
drop view v1;
drop table t1,t2,t3,t4;

The update statement above succeeds after which we have

MariaDB [test]> select * from t1;
+------+
| a    |
+------+
|    0 |
|    3 |
|    9 |
+------+

It means that at least the condition t1.a<t4.a was not checked.
I debugger we see that the condition that is checked after a row update is actually:

t1.a > t2.a and t4.a > t3.a



 Comments   
Comment by Igor Babaev [ 2020-07-30 ]

MySQL 8.0 currently properly forms the condition checked when updating rows of a view whose definition contains WITH CHECK OPTION clause. It makes sense to port the corresponding code.

Comment by Igor Babaev [ 2020-07-30 ]

This bug was actually fixed in MySQL 8.0 (see the commit 44395ac15f239c07dc7e681cadd44c60216ad27).
I would recommend just to port the fix from there together with test cases.

Postgres 9.6 also handles the above test case properly. It returns:

ERROR: new row violates check option for view "v1" Detail: Failing row contains (9).

Generated at Thu Feb 08 09:21:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.