You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#19418619 - SELECT QUERY WITH INVALID TIME WORKS FINE
BUT SP FAILS UNDER STRICT MODE
Description:
STRICT sql mode does not apply to SELECT statement except
for invalid arguments to sleep(). SELECT statement gives
warning for invalid data in STRICT mode, which is correct
behavior. If same SELECT statement is executed from within
Stored Procedure, it gives error and abort statement.
Statement behavior should not change if executed from Stored
Procedure. Same case exist for SET statement.
Another issue, CREATE TABLE statement fails while CREATE
INDEX statement passes for too long indexes in STRICT mode.
Index creation should behave same if executed from
CREATE TABLE or CREATE INDEX statement.
Analysis:
This is a regression from WL#6891. Stored Procedures are
executed in the sql mode they were created. When SP was
created in STRICT mode, Strict_error_handler was pushed
before executing statements inside the Stored Procedure.
This upgrades warnings to error for every SELECT statement.
Other side effects of above change are:
- Changing STRICT sql mode inside Stored Procedure would
have no effect.
- As documented, evaluation of SP and SF parameters should
depend on the current sql mode instead of the mode in
which SP/SF was created. Behavior got changed with WL#6891
and parameter evaluation started using sql_mode in which
SP/SF were created.
Strict_error_handler was missing check for CREATE INDEX
statement. So, where CREATE TABLE will give error for too long
indexes, CREATE INDEX statement will succeed with warning in
STRICT mode.
Fix:
Fixed code to push Strict_error_handler when required.
SELECT inside and outside Stored Procedure will behave
same. Exception for this is when we do SELECT on variables
declared inside Stored Procedure.
Consider the procedure :
create procedure proc1()
begin
declare div_zero integer;
select 1/0 into div_zero;
end
Here, SELECT to assign invalid value to 'div_zero' will
fail in STRICT mode as it follows the rules of assigning a
value to INTEGER column in a table. There is no behavior
change here.
Same case applies to SET statement.
Now STRICT mode setting can be changed inside Stored
Procedures and parameter evaluation will depend on current
sql mode.
Added check for CREATE INDEX statement in Strict_error_handler.
ERROR 42000: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
96
+
ERROR 42000: Specified key was too long; max key length is 767 bytes
97
97
show warnings;
98
98
Level Code Message
99
-
Warning 1071 Specified key was too long; max key length is 767 bytes
100
-
Error 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
99
+
Error 1071 Specified key was too long; max key length is 767 bytes
101
100
set global innodb_large_prefix=1;
102
-
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';
103
101
create index idx2 on worklog5743_1(a2(4000));
104
-
ERROR 42000: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
105
-
SET sql_mode = default;
102
+
ERROR 42000: Specified key was too long; max key length is 3072 bytes
106
103
show warnings;
107
104
Level Code Message
105
+
Error 1071 Specified key was too long; max key length is 3072 bytes
108
106
create index idx3 on worklog5743_1(a2(436));
109
107
ERROR 42000: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
110
108
show warnings;
@@ -122,6 +120,7 @@ create index idx6 on worklog5743_1(a1, a2(428));
122
120
show warnings;
123
121
Level Code Message
124
122
set global innodb_large_prefix=0;
123
+
SET sql_mode= '';
125
124
create index idx1 on worklog5743_2(a2(4000));
126
125
Warnings:
127
126
Warning 1071 Specified key was too long; max key length is 767 bytes
@@ -253,6 +252,7 @@ Error 1071 Specified key was too long; max key length is 3072 bytes
253
252
create index idx7 on worklog5743_16(a1, a2(2000), a3(1068));
254
253
show warnings;
255
254
Level Code Message
255
+
set sql_mode= default;
256
256
insert into worklog5743_1 values(9, repeat("a", 10000));
257
257
insert into worklog5743_2 values(9, repeat("a", 10000));
258
258
insert into worklog5743_4 values(9, repeat("a", 10000));
@@ -382,6 +382,7 @@ a4 varchar(3072),
382
382
a5 varchar(3069),
383
383
a6 varchar(3068))
384
384
ROW_FORMAT=DYNAMIC;
385
+
SET sql_mode='';
385
386
create index idx1 on worklog5743(a2);
386
387
Warnings:
387
388
Warning 1071 Specified key was too long; max key length is 3072 bytes
@@ -391,11 +392,11 @@ Warning 1071 Specified key was too long; max key length is 3072 bytes
391
392
create index idx3 on worklog5743(a4);
392
393
show warnings;
393
394
Level Code Message
395
+
SET sql_mode= default;
394
396
create index idx4 on worklog5743(a1, a2);
395
397
ERROR 42000: Specified key was too long; max key length is 3072 bytes
396
398
show warnings;
397
399
Level Code Message
398
-
Warning 1071 Specified key was too long; max key length is 3072 bytes
399
400
Error 1071 Specified key was too long; max key length is 3072 bytes
400
401
create index idx5 on worklog5743(a1, a5);
401
402
ERROR 42000: Specified key was too long; max key length is 3072 bytes
@@ -473,6 +474,7 @@ rollback;
473
474
drop table worklog5743;
474
475
### Test 7 ###
475
476
create table worklog5743(a TEXT not null) ROW_FORMAT=DYNAMIC;
477
+
SET sql_mode='';
476
478
create index idx1 on worklog5743(a(3073));
477
479
Warnings:
478
480
Warning 1071 Specified key was too long; max key length is 3072 bytes
0 commit comments