Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL)
-
None
Description
In this script:
DROP TABLE IF EXISTS t1;
|
CREATE TABLE t1 (a INT, b ENUM('2','3'));
|
INSERT INTO t1 VALUES(2,'2');
|
UPDATE t1 SET b=a;
|
SELECT b FROM t1;
|
copying is done using val_int() method of the field "a", which returns 2 and then further converts to ENUM value[2], which is '3'. So the script returns:
+------+
|
| b |
|
+------+
|
| 3 |
|
+------+
|
The same behavior is demonstrated in this script:
DROP TABLE IF EXISTS t1,t2;
|
CREATE TABLE t1 (a INT);
|
INSERT INTO t1 VALUES (2);
|
CREATE TABLE t2 (b ENUM('2','3'));
|
INSERT INTO t2 SELECT * FROM t1;
|
SELECT *FROM t2;
|
+------+
|
| b |
|
+------+
|
| 3 |
|
+------+
|
Now if I use ALTER:
DROP TABLE IF EXISTS t1;
|
CREATE TABLE t1 (a INT);
|
INSERT INTO t1 VALUES(2);
|
ALTER TABLE t1 CHANGE a b ENUM('2','3');
|
SELECT * FROM t1;
|
it goes through val_str() of the field "a" which returns string '2', so the result is:
+------+
|
| b |
|
+------+
|
| 2 |
|
+------+
|
All three cases should return the same result.
Attachments
Activity
Interestingly enough:
MySQL 5.5.48:
+---+-----+
|
| i | bug |
|
+---+-----+
|
| 1 | |
|
| 2 | |
|
| 3 | 0 |
|
+---+-----+
|
I see a regression in the treatment of enums and ints in general here.
create table mariadb_bug ( i int primary key, bug enum('0','1') NOT NULL DEFAULT '0' );
insert into mariadb_bug values (1, 0),(2, 0),(3, 1);
select * from mariadb_bug;
MySQL 5.1.50:+---+-----+| i | bug |+---+-----+| 1 | 0 || 2 | 0 || 3 | 1 |+---+-----+MariaDB 10.0.23:+---+-----+| i | bug |+---+-----+| 1 | || 2 | || 3 | 0 |+---+-----+MariaDB 10.1.14:+---+-----+| i | bug |+---+-----+| 1 | || 2 | || 3 | 0 |+---+-----+