expression, executor: castStringAsTime returns null when sql_mode is not strict

[XuHuaiyu]

What problem does this PR solve?

castStringAsTime returns null when sql_mode is not strict.
Before this commit, the following query will raise an error:

tidb> set @@sql_mode = '';
Query OK, 0 rows affected (0.00 sec)

tidb> create table t(a datetime);
Query OK, 0 rows affected (0.01 sec)

tidb> insert into t value("1999-12-12");
Query OK, 1 row affected (0.00 sec)

tidb> update t set a = '';
ERROR 1292 (22007): invalid time format: ''

What is changed and how it works?

1. Return warning when sql_mode is not strict in builtinCastStringAsTime.
2. Return null when any error or warning happens in builtinCastStringAsTime.

Check List

Tests

• Integration test

Code changes

• Has exported function/method change

Side effects

It's really hard to make all the behavior to be compatiable with MySQL when cast a string as datetime. The results of MySQL are different between implicit cast and explict cast.
e.g.

mysql> set @@sql_mode='';                                                           Query OK, 0 rows affected (0.00 sec)

mysql> select year("20123-12-12");
+---------------------+
| year("20123-12-12") |
+---------------------+
|                NULL | -- The implicit cast result of "20123-12-12" is NULL.
+---------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1292 | Incorrect datetime value: '20123-12-12' | 
+---------+------+-----------------------------------------+
1 row in set (0.00 sec)

mysql> select year(cast("20123-12-12" as datetime));
+---------------------------------------+
| year(cast("20123-12-12" as datetime)) |
+---------------------------------------+
|                                  NULL | -- The explicit cast result is NULL.
+---------------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> update t set a = "20123-12-12";
Query OK, 0 rows affected, 1 warning (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 1

mysql> select * from t;
+---------------------+
| a                   |
+---------------------+
| 0000-00-00 00:00:00 | -- The implicit cast result of "20123-12-12" is ZeroDatetime.
+---------------------+
1 row in set (0.00 sec)

mysql> update t set a=cast("20123-12-12" as datetime);
Query OK, 1 row affected, 1 warning (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 1

mysql> select * from t;
+------+
| a    |
+------+
| NULL | -- The explicit cast result is NULL.
+------+
1 row in set (0.00 sec)

We return NULL here despite of implict cast or explicit cast. Thus it may break some backward compatibility with MySQL.
e.g.

tidb> select unix_timestamp('20102-12-12');
+-------------------------------+
| unix_timestamp('20102-12-12') |
+-------------------------------+
|                          NULL | -- MySQL returns 0 here
+-------------------------------+
1 row in set (0.00 sec)

Maybe we need to check the warning as this comment mentioned.

2. Some compatibility problems are still not resolved, like the different error message between implicit cast and explicit cast.
   e.g.

MySQL(root@127.0.0.1:test) > set @@sql_mode='';
Query OK, 0 rows affected (0.00 sec)

MySQL(root@127.0.0.1:test) > insert into t values(cast('' as datetime));                                                                                                                                                                                                                      Query OK, 1 row affected, 1 warning (0.01 sec)

MySQL(root@127.0.0.1:test) > show warnings;
+---------+------+------------------------------+
| Level   | Code | Message                      |
+---------+------+------------------------------+
| Warning | 1292 | Incorrect datetime value: '' | 
+---------+------+------------------------------+
1 row in set (0.00 sec)

MySQL(root@127.0.0.1:test) > insert into t values('');
Query OK, 1 row affected, 1 warning (0.02 sec)

MySQL(root@127.0.0.1:test) > show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1265 | Data truncated for column 'a' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)

Related changes

---

This change is 

[XuHuaiyu]

/run-all-tests

[XuHuaiyu]

PTAL @tiancaiamao @zz-jason

[XuHuaiyu]

PTAL @tiancaiamao @winoros

[XuHuaiyu]

PTAL @zz-jason @winoros @tiancaiamao

[zz-jason]

LGTM

[tiancaiamao]

What happen if b.tp.Tp is mysql.TypeTimestamp? 00-00-00 00:00:00 seems not a legal timestamp value ?

[zz-jason]

Here the return value is either a NULL or an error. The returned types.Time{} is never used.

[zz-jason]

@tiancaiamao @winoros @eurekaka PTAL

[tiancaiamao]

LGTM

[zz-jason]

should we cherry-pick this commit to release-2.1? @XuHuaiyu