maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

  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'