Date parameters are converted to string automatically

[YangKeao]

TiDB handles the date parameters as string, which is not expected. TiDB should construct a data, but not string for these parameters. See:

		case mysql.TypeDate, mysql.TypeTimestamp, mysql.TypeDatetime:
			if len(paramValues) < (pos + 1) {
				err = mysql.ErrMalformPacket
				return
			}
			// See https://dev.mysql.com/doc/internals/en/binary-protocol-value.html
			// for more details.
			length := paramValues[pos]
			pos++
			switch length {
			case 0:
				tmp = types.ZeroDatetimeStr
			case 4:
				pos, tmp = binaryDate(pos, paramValues)
			case 7:
				pos, tmp = binaryDateTime(pos, paramValues)
			case 11:
				pos, tmp = binaryTimestamp(pos, paramValues)
			case 13:
				pos, tmp = binaryTimestampWithTZ(pos, paramValues)
			default:
				err = mysql.ErrMalformPacket
				return
			}
			args[i] = types.NewDatum(tmp) // FIXME: After check works!!!!!!
			continue

[YangKeao]

This bugs turns to be quite complicated, especially about warn handling.

The warnings are reset during statement execution, after parsing parameters, so we cannot add warnings during the parsing of parameters 🤦. Another difficult part is that different statements can have different behaviors for warnings (related with TruncateAsWarning and something, see ResetContextOfStmt...), so we should parse the parameters after parsing the statement, which needs a big refractor.

This bug doesn't affect too much, because most of the time we don't care about the type of an argument, and it can be implicitly converted in most cases. The only problem comes into my mind is about the JSON. string and datetime have different json_type.

[YangKeao]

Oops, it actually brings more problem if the user converts it to another type. For example:

SELECT CAST(? AS SIGNED)

If the ? is a time: 2001-10-20 10:10:59.500000, convert a datetime to signed will give 20011020101100LL, but convert the string to signed will give 2001. That's why test_temporal_param case in mysql_client_test failed.