Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2, 11.3(EOL), 11.4
-
None
Description
CREATE OR REPLACE TABLE t1 AS SELECT UUID(); |
SHOW CREATE TABLE t1; |
+-------+-------------------------------------------------------------------------------------------------------------------+
|
| Table | Create Table |
|
+-------+-------------------------------------------------------------------------------------------------------------------+
|
| t1 | CREATE TABLE `t1` (
|
`UUID()` uuid DEFAULT NULL
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci |
|
+-------+-------------------------------------------------------------------------------------------------------------------+
|
Looks wrong. The column should be NOT NULL, as UUID() never returns NULL.
The problem happens because Item_func_uuid unintentionally derived this behavior from Item_str_func:
bool Item_str_func::fix_fields(THD *thd, Item **ref) |
{
|
bool res= Item_func::fix_fields(thd, ref); |
/* |
In Item_str_func::check_well_formed_result() we may set null_value
|
flag on the same condition as in test() below.
|
*/
|
if (thd->is_strict_mode()) |
set_maybe_null();
|
return res; |
}
|
Notice the line with set_maybe_null().
Conceptually, Item_func_uuid should not derive (directly or indirectly) from Item_str_func.
It returns the UUID data type, so it should not derive unrelated CHAR/VARCHAR/TEXT behavior.
This is not a very important flaw. However, we're going to add UUIDv4() and UUIDv7() functions soon. It's a good idea to fix this behavior before adding the new functions, to avoid propagating of the flaw into the new functions.
Attachments
Issue Links
- blocks
-
MDEV-11339 Support UUID v4 generation
-
- Closed
-
-
-
- Closed
-
- causes
-
-
- In Review
-
- relates to
-
MDEV-4958 Adding datatype UUID
-
- Closed
-