Problem:
The following functions-
- `Item_func_last_day::get_date`
- `Item_date_typecast::get_date`
- `Item_datetime_typecast::get_date` forwarded the TIME_INTERVAL_DAY /
TIME_INTERVAL_hhmmssff flags, set by an enclosing EXTRACT, into the
DATE/DATETIME conversion of their argument.This made, for ex:
LAST_DAY(200012010000) and CAST(200012010000 AS DATETIME) parse number
as TIME interval instead of a DATETIME. Under ZERO_DATE_TIME_CAST
that hour became an out-of-range month, overflowing days_in_month in
`check_date` and invalidating the Datetime.
Fix:
A DATE / DATETIME can never be an interval, so suppress the
TIME_INTERVAL_hhmmssff / TIME_INTERVAL_DAY flags when `LAST_DAY` and
`CAST` converts its argument. Also add a debug assert in `check_date`
to catch any future caller that violates its "month is assumed valid"
contract.
In the major release of MariaDB 12.3.1, MariaDB this change to
refactor ssl_verify_server_cert to master_ssl_verify_server_cert in
commit in 89bd6b00.
However, these values are different types. While ssl_verify_server_cert
is my_bool
type, the master_ssl_verify_server_cert is trilean type which accepts
three possible values (Yes/No/Default). When reading the value of the
argument using !*(my_bool*)arg in mysql_options, trilean type value
can't be retrieved because it accesses the wrong memory address by just
passing the master_ssl_verify_server_cert, causing the
master_ssl_verify_server_cert still behaves as "ON" when it's set to
"OFF".
This commit changes the implementation to
`master_ssl_verify_server_cert.value` retrieve the correct value.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Reviewed-by: Jimmy Hú <jimmy.hu@mariadb.com>
Reviewed-by: Georgi Kodinov <joro@mariadb.org>
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
number-to-time conversion was too eagerly capping the value.
A string "9000090" was invalid time, because of 90 seconds.
But number-to-time was capping first, validating later,
to 9000090->time worked. Let's fix it.
also, let's make invalid time values in a string field include
the field name in the warning message, just like invalid time
values in a numeric field do.
It returns the DATETIME data type (which is the closest to Oracle's DATE).
The following Oracle formats are supported:
Truncate to day: DD, DDD,J
Truncate to month: MM,MON,MONTH,RM
Truncate to Year: SYEAR,SYYYY,Y,YEAR,YY,YYY,YYYY
TRUNC(date) is same as TRUNC(date, "DD")
This patch incorporates a fix for:
MDEV-37414 SIGSEGV in Binary_string::c_ptr | Item_func_trunc::get_date
Fixing the problem that the code did not take into
account that args[1] can return SQL NULL.
main/statistics_json.result is updated for f8ba5ced55 (MDEV-36099)
The test uses 'delete from t1' in many places and then populates
the table again. The natural order of rows in a MyISAM table is well
defined and the test was implicitly relying on that.
before f8ba5ced55 delete was deleting rows one by one, using
ha_myisam::delete_row() because the connection was stuck in rbr mode.
This caused rows to be shown in the reverse insertion order (because of
the delete link list).
MDEV-36099 fixes this bug and the server now correctly uses
ha_myisam::delete_all_rows(). This makes rows to be shown in the
insertion order as expected.
This is the same as MDEV-35368, which was previously incompletely fixed
(on *nix-only, for unix socket connections)
This time, we fix it compatibly to Connector/C, by not verifying
server certificate for local connections, which, in addition to socket
and named pipe, are also "127.0.0.1" and "::1", and on Windows "localhost"
as well.
The corresponding code in Connector/C is was added by
1287c901dc8515823d28edcebfe4be65e6c5a6b3.
It remain a good question whether mariabackup should use SSL at all
since all it does are local connections, for "BACKUP STAGE" stuff.
According to ISO 8601 standard, 'T' should be followed by the time of
day. If a date ends with only 'T', throw an error in strict mode and a
warning in other modes.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
Migrate `mysys/errors.c`, `sql-common/errmsg.c` and a couple of
insignificant loose ends to use suffix-based, `-Wformat`-compatible
`my_snprintf` format extensions introduced in MDEV-21978
This commit is the final batch of MDEV-21978’s migration process.
While GCC `-Wformat` (with `ATTRIBUTE_FORMAT`) can catch obsolete or
malformed format string literals, formats originating from other sources
(such as those strings headers) (still) require manual review.
Thus, after all the automatic `-Wformat` complaints fixed in previous
commits, I’ve done a manual `grep` and caught these final matches.
* rpl.rpl_system_versioning_partitions updated for MDEV-32188
* innodb.row_size_error_log_warnings_3 changed error for MDEV-33658
(checks are done in a different order)
Partial commit of the greater MDEV-34348 scope.
MDEV-34348: MariaDB is violating clang-16 -Wcast-function-type-strict
Change the type of my_hash_get_key to:
1) Return const
2) Change the context parameter to be const void*
Also fix casting in hash adjacent areas.
Reviewed By:
============
Marko Mäkelä <marko.makela@mariadb.com>
Fix various typos, in comments and DEBUG statements, and code changes
are non-functional.
All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.
MDEV-32188 make TIMESTAMP use whole 32-bit unsigned range
- Changed usage of timeval to my_timeval as the timeval parts on windows
are 32-bit long, which causes some compiler issues on windows.
