bp #53050
Related PR: #40695
Problem Summary:
pr #40695 introduced the function `from_iso8601_date`, which parses the
string to get year、mouth、 day, and sets the date value through the
`set_time_unit` function.
Since `set_time_unit` lacks some judgment on mouth, it may get an
illegal date in the end, which may cause core in debug mode.
sql : `select from_iso8601_date('2023-00-01');`
```
F20250709 09:50:14.366984 3587796 vdatetime_value.h:1222] Check failed: date_v2_value_.month_ != 0
*** Check failure stack trace: ***
@ 0x559bd7050d96 google::LogMessage::SendToLog()
@ 0x559bd704d7e0 google::LogMessage::Flush()
@ 0x559bd70515d9 google::LogMessageFatal::~LogMessageFatal()
@ 0x559bc725a570 doris::DateV2Value<>::set_time_unit<>()
@ 0x559bc7257380 doris::vectorized::FromIso8601DateV2::execute()
@ 0x559bc7255a88 doris::vectorized::FunctionOtherTypesToDateType<>::execute_impl()
@ 0x559bc09e0781 doris::vectorized::DefaultExecutable::execute_impl()
@ 0x559bc423aa20 doris::vectorized::PreparedFunctionImpl::_execute_skipped_constant_deal()
@ 0x559bc4234938 doris::vectorized::PreparedFunctionImpl::execute_without_low_cardinality_columns()
@ 0x559bc4233f42 doris::vectorized::PreparedFunctionImpl::default_implementation_for_nulls()
@ 0x559bc423a773 doris::vectorized::PreparedFunctionImpl::_execute_skipped_constant_deal()
@ 0x559bc4234938 doris::vectorized::PreparedFunctionImpl::execute_without_low_cardinality_columns()
@ 0x559bc4234a57 doris::vectorized::PreparedFunctionImpl::execute()
```
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [ ] Regression test
- [ ] Unit Test
- [ ] Manual test (add detailed scripts or steps below)
- [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
- [ ] Previous test can cover this change.
- [ ] No code files have been changed.
- [ ] Other reason <!-- Add your reason? -->
- Behavior changed:
- [ ] No.
- [ ] Yes. <!-- Explain the behavior change -->
- Does this need documentation?
- [ ] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->
## Proposed changes
```
mysql [test]>set DEBUG_SKIP_FOLD_CONSTANT = true;
Query OK, 0 rows affected (0.00 sec)
mysql [test]>select cast(unix_timestamp("2024-01-01",'yyyy-MM-dd') as bigint);
+------------------------------------------------------------+
| cast(unix_timestamp('2024-01-01', 'yyyy-MM-dd') as BIGINT) |
+------------------------------------------------------------+
| 1704038400000000 |
+------------------------------------------------------------+
```
now
```
mysql [test]>select cast(unix_timestamp("2024-01-01",'yyyy-MM-dd') as bigint);
+------------------------------------------------------------+
| cast(unix_timestamp('2024-01-01', 'yyyy-MM-dd') as BIGINT) |
+------------------------------------------------------------+
| 1704038400 |
+------------------------------------------------------------+
1 row in set (0.01 sec)
```
The column does not have a scale set, but the cast uses the scale to
perform the cast.
<!--Describe your changes.-->
## Proposed changes
Issue Number: close #xxx
<!--Describe your changes.-->
1 enable the cases about str_to_date, which have been muted because some parallel config influence.
2 serialise some cases which called admin set config
remove case
```sql
select datediff('10000-10-31', '2010-10-15')
```
because Nereids throw exception when cast '10000-10-31' to date,
but legacy planner return null on it
UNIX_TIMESTAMP function data format parameter supports 'yyyy-MM-dd HH:mm:ss'
The implementation is the same as the date_format function
before:
```sql
mysql> select UNIX_TIMESTAMP('2023-09-18 00:00:00','yyyy-MM-dd HH:mm:ss');
+--------------------------------------------------------------+
| unix_timestamp('2023-09-18 00:00:00', 'yyyy-MM-dd HH:mm:ss') |
+--------------------------------------------------------------+
| NULL |
+--------------------------------------------------------------+
1 row in set (0.04 sec)
```
now:
```sql
mysql> select UNIX_TIMESTAMP('2023-09-18 00:00:00','yyyy-MM-dd HH:mm:ss');
+------------+
| 1694966400 |
+------------+
| 1694966400 |
+------------+
1 row in set (0.01 sec)
```
* [fix](load) in strict mode, return error for load and insert if datatype convert fails
Revert "[fix](MySQL) the way Doris handles boolean type is consistent with MySQL (#19416)"
This reverts commit 68eb420cabe5b26b09d6d4a2724ae12699bdee87.
Since it changed other behaviours, e.g. in strict mode insert into t_int values ("a"),
it will result 0 is inserted into table, but it should return error instead.
* fix be ut
* fix regression tests
* [bugfix](VecDateTimeValue) eat the value of microsecond in function from_date_format_str
* add sql based regression test
Co-authored-by: xiaojunjie <xiaojunjie@baidu.com>
