Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
10.1.2
-
None
Description
As discussed, the following revision has an unexpected side-effect
* commit 227510e039b4ec6bff3096a4b9b39847551dab1a
|
| Author: Sergei Golubchik <serg@mariadb.org>
|
| Date: Sat Nov 8 17:37:19 2014 +0100
|
|
|
| parser cleanup: don't store field properties in LEX, use Create_field directly
|
|
|
| length/dec/charset are still in LEX, because they're also used
|
| for CAST and dynamic columns.
|
|
|
| also
|
| 1. fix "MDEV-7041 COLLATION(CAST('a' AS CHAR BINARY)) returns a wrong result"
|
| 2. allow BINARY modifier in stored function RETURN clause
|
| 3. allow "COLLATION without CHARSET" in SP/SF (parameters, RETURN, DECLARE)
|
| 4. print correct variable name in error messages for stored routine parameters
|
Before this change, column definition c DOUBLE(0,0) was rejected with ER_TOO_BIG_DISPLAYWIDTH:
MariaDB [test]> create table t1 (c double(0,0)); |
ERROR 1439 (42000): Display width out of range for 'c' (max = 255) |
Since this revision, it is accepted and the column is stored as DOUBLE:
MariaDB [test]> create table t1 (c double(0,0)); |
Query OK, 0 rows affected (0.55 sec) |
|
|
MariaDB [test]> insert into t1 values (1234567890123456.1234567890123456); |
Query OK, 1 row affected (0.06 sec)
|
|
|
MariaDB [test]> select * from t1; |
+----------------------+ |
| c |
|
+----------------------+ |
| 1.234567890123456e15 |
|
+----------------------+ |
1 row in set (0.00 sec) |
|
|
MariaDB [test]> show create table t1 \G |
*************************** 1. row ***************************
|
Table: t1 |
Create Table: CREATE TABLE `t1` ( |
`c` double DEFAULT NULL |
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
1 row in set (0.00 sec) |
I don't see anything bad in it, but since it's unexpected it is suspicious.
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
I think new behavior is better. ER_TOO_BIG_DISPLAYWIDTH looks weird. Something like "incorrect width" could've been even better, but is probably not worth a new error message just for that.
Some storage_engine tests (col_opt_not_null col_opt_null col_opt_unsigned col_opt_zerofill type_float) have been adjusted to accept the new behavior. If you decide to change it, the tests should be updated as well. The easy way to do it is to run MTR as
ENGINE=MyISAM perl ./mtr <test name> and to re-record the result file. As of now, these tests don't have overlays for any engines, so it should be enough; but by the time you get to it some overlays can be added. In any case, even easier way to fix the tests is to reassign this issue back to me, and I'll take care of that.