Comment 4 for bug 660779

I have a fix for this particular case (UPDATE), but I need to handle other multi-row affecting statements that could fail in a similar manner. The only one that I can think of that would be similar to this is INSERT..SELECT. Unfortunately, the logic of the code is not the same as UPDATE, so I need to figure that out.

I have a test case for INSERT..SELECT that confirms the problem exists for this statement:

CREATE TABLE t1
(pk INT NOT NULL AUTO_INCREMENT,
col_int1 INT,
col_int2 INT,
col_int_not_null INT NOT NULL,
PRIMARY KEY (pk) );

INSERT INTO t1 (col_int1, col_int2, col_int_not_null) VALUES (1,1,1);
INSERT INTO t1 (col_int1, col_int2, col_int_not_null) VALUES (NULL,1,1);
INSERT INTO t1 (col_int1, col_int2, col_int_not_null) VALUES (2,1,3);

CREATE TABLE t2 (pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY, a INT);
INSERT INTO t2 (a) VALUES (1), (2), (NULL);

BEGIN;
--ERROR ER_BAD_NULL_ERROR
INSERT INTO t1 (col_int_not_null) SELECT a FROM t2;
COMMIT;

The Transaction statement will have INSERTS for the '1' and '2' values.