Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL)
-
None
Description
SET sql_mode=DEFAULT; |
DROP PROCEDURE IF EXISTS p1; |
DROP TABLE IF EXISTS t1,t2; |
DELIMITER $$
|
CREATE PROCEDURE p1() |
BEGIN
|
DECLARE a INT DEFAULT 10; |
DECLARE cur1 CURSOR FOR SELECT a; |
BEGIN |
DECLARE rec1 ROW TYPE OF cur1; |
CREATE TABLE t2 AS SELECT rec1.a; |
SHOW CREATE TABLE t2; |
DROP TABLE t2; |
END; |
END; |
$$
|
DELIMITER ;
|
CALL p1();
|
+-------+-----------------------------------------------------------------------------------------------+
|
| Table | Create Table |
|
+-------+-----------------------------------------------------------------------------------------------+
|
| t2 | CREATE TABLE `t2` (
|
`rec1.a` bigint(20) DEFAULT NULL
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
|
+-------+-----------------------------------------------------------------------------------------------+
|
Notice, it created a BIGINT(20) column. Looks wrong. The expected type is INT(11)), as in the declaration of the procedure variable a.
The problem happens at the cursor materialization time, when create_tmp_field_from_item() is called.
It calls Item::create_tmp_field(), which erroneously makes a BIGINT field for Item_splocal with INT data and max_length=11.
The execution path should not go through Item::create_tmp_field() to avoid conversion from INT(11) to BIGINT(11).
Attachments
Issue Links
- blocks
-
MDEV-4912 Data type plugin API version 1
- Closed