|
PREPARE stmt FROM "SELECT LEFT('a','b')";
|
SHOW WARNINGS;
|
EXECUTE stmt;
|
SHOW WARNINGS;
|
returns the following:
Query OK, 0 rows affected, 1 warning (0.00 sec)
|
Statement prepared
|
|
+---------+------+----------------------------------------+
|
| Level | Code | Message |
|
+---------+------+----------------------------------------+
|
| Warning | 1292 | Truncated incorrect INTEGER value: 'b' |
|
+---------+------+----------------------------------------+
|
1 row in set (0.00 sec)
|
|
+---------------+
|
| LEFT('a','b') |
|
+---------------+
|
| |
|
+---------------+
|
1 row in set, 2 warnings (0.00 sec)
|
|
+---------+------+----------------------------------------+
|
| Level | Code | Message |
|
+---------+------+----------------------------------------+
|
| Warning | 1292 | Truncated incorrect INTEGER value: 'b' |
|
| Warning | 1292 | Truncated incorrect INTEGER value: 'b' |
|
+---------+------+----------------------------------------+
|
2 rows in set (0.00 sec)
|
Notice, one warning is sent during PREPARE.
Then two warnings are sent during EXECUTE:
- one warning during fix_length_and_dec()
- another warning during the actual query execution
There could be less warnings.
Serg proposed that fix_length_and_dec() could put args[1] into either of these:
- Item_int
- Item_cache_int
- Item_int_with_ref
This would fix redundant warnings and help to avoid unnecessary strtoll10() calls per every row.
The problem is also repeatable with:
PREPARE stmt FROM "SELECT LPAD('a','b','c')";
|
SHOW WARNINGS;
|
EXECUTE stmt;
|
SHOW WARNINGS
|
|