Hello Sergei. On 7/29/22 16:25, Sergei Golubchik wrote: As discussed on slack, some new circumstances were found and the patch needs to be changed. So I'm answering only this issue for now: <cut>
@@ -3647,6 +3643,15 @@ mysql_prepare_create_table(THD *thd, HA_CREATE_INFO *create_info, { Field::utype type= (Field::utype) MTYP_TYPENR(sql_field->unireg_check);
+ if (sql_field->default_value && + sql_field->default_value->expr->type() == Item::NULL_ITEM && + sql_field->flags & NOT_NULL_FLAG && + !(sql_field->flags & AUTO_INCREMENT_FLAG)) + { + my_error(ER_INVALID_DEFAULT, MYF(0), sql_field->field_name.str); + DBUG_RETURN(TRUE); + }
^^^ now obvious errors are caught only during EXECUTE, although it's already clear at the PREPARE stage that the DEFAULT is wrong:
MariaDB [test]> PREPARE stmt FROM 'CREATE TABLE T1 (a INT NOT NULL DEFAULT NULL)'; Query OK, 0 rows affected (0.000 sec) Statement prepared
MariaDB [test]> EXECUTE stmt; ERROR 1067 (42000): Invalid default value for 'a'
I suggest we still catch non-unambiguous cases (when nothing depends on system variables) during PREPARE. Inside some existing or a new Type_handler method.
it's quite tricky. At most I can restore the old check and _some_ cases will be reported at prepare (explicit NOT NULL DEFAULT NULL, that is).
I suggest this should be restored. It did fail before the change: MariaDB [test]> PREPARE stmt FROM 'CREATE TABLE T1 (a INT NOT NULL DEFAULT NULL)'; ERROR 1067 (42000): Invalid default value for 'a'