From 0c3a2d80bb6c327ef2e62a1079c5d676dc19d4af Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 3 Sep 2026 13:53:30 +0900 Subject: [PATCH] Fix DATATIME typo and precision/scale wording sql-mode.md: DATATIME was a misspelling of DATETIME. tidb-troubleshooting-map.md: DECIMAL(a, b) uses a for precision and b for scale, not both for precision. Found while reviewing CodeRabbit feedback on the Japanese translation of these two files. --- sql-mode.md | 2 +- tidb-troubleshooting-map.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sql-mode.md b/sql-mode.md index 312b14ca09c65..104172a3f9c68 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -41,7 +41,7 @@ In this statement, `modes` is a set of modes separated by commas (','). You can | `STRICT_ALL_TABLES` | For transactional tables, rolls back the entire transaction statement after an invalid value is inserted. (full support) | | `NO_ZERO_IN_DATE` | Strict mode, where dates with a month or day part of `0` are not accepted. If you use the `IGNORE` option, TiDB inserts '0000-00-00' for a similar date. In non-strict mode, this date is accepted but a warning is returned. (full support) | `NO_ZERO_DATE` | Does not use '0000-00-00' as a legal date in strict mode. You can still insert a zero date with the `IGNORE` option. In non-strict mode, this date is accepted but a warning is returned. (full support)| -| `ALLOW_INVALID_DATES` | In this mode, the system does not check the validity of all dates. It only checks the month value ranging from `1` to `12` and the date value ranging from `1` to `31`. The mode only applies to `DATE` and `DATATIME` columns. All `TIMESTAMP` columns need a full validity check. (full support) | +| `ALLOW_INVALID_DATES` | In this mode, the system does not check the validity of all dates. It only checks the month value ranging from `1` to `12` and the date value ranging from `1` to `31`. The mode only applies to `DATE` and `DATETIME` columns. All `TIMESTAMP` columns need a full validity check. (full support) | | `ERROR_FOR_DIVISION_BY_ZERO` | If this mode is enabled, the system returns an error when handling division by `0` in data-change operations (`INSERT` or `UPDATE`).
If this mode is not enabled, the system returns a warning and `NULL` is used instead. (full support) | | `NO_AUTO_CREATE_USER` | Prevents `GRANT` from automatically creating new users, except for the specified password (full support)| | `HIGH_NOT_PRECEDENCE` | The precedence of the NOT operator is such that expressions such as `NOT a BETWEEN b AND c` are parsed as `NOT (a BETWEEN b AND c)`. In some older versions of MySQL, this expression is parsed as `(NOT a) BETWEEN b AND c`. (full support) | diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 7c3e3771ff703..3a3715ad7614e 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -181,7 +181,7 @@ For more information about troubleshooting OOM, see [Troubleshoot TiDB OOM Issue The multiplication of `Decimal` does not have this issue, because the out-of-bounds is bypassed, and the precision is set to the maximum precision limit. - - Solution: You can bypass this issue by manually adding `Cast(xx as decimal(a, b))`, in which `a` and `b` are the target precisions. + - Solution: You can bypass this issue by manually adding `Cast(xx as decimal(a, b))`, in which `a` is the target precision and `b` is the target scale. ### 3.5 Slow query issues