| Bug #77883 | Only able to get ZERO from warning_count. | ||
|---|---|---|---|
| Submitted: | 30 Jul 2015 12:30 | Modified: | 25 Oct 2018 8:21 |
| Reporter: | Peter Laursen (Basic Quality Contributor) | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: Errors | Severity: | S3 (Non-critical) |
| Version: | 5.6.25 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[30 Jul 2015 12:31]
Peter Laursen
Sorry - first line should have read like "I am not able to get anything else than "0" returned from warning_count."
[30 Jul 2015 12:49]
Peter Laursen
The warning_count in the C-API (https://dev.mysql.com/doc/refman/5.6/en/mysql-warning-count.html) it seems to work (with the C-API from MariaDB at least). If the server variable and API function do not return the same, differences should be elaborated somewhere in docs.
[3 May 2018 6:31]
Chiranjeevi Battula
Hello Peter, Thank you for the bug report. Thanks, Chiranjeevi.
[25 Oct 2018 8:21]
Erlend Dahl
Posted by developer - Jens Even Blomsoy:
Update:
Using;
SHOW COUNT(*) WARNINGS;
or
SELECT @@warning_count;
Produces the wanted and expected result.
By doing SHOW VARIABLES LIKE 'warning_count'; one touches a table in the
query and the warning_count is reset to take into account the errors that may
occur according to the documentation.
The warning_count from this query is in a way correct in the sense that it
counts the number of warnings produced by the same query. This is although
confusing. So the question is if this should be changed to view the
warning_count of the previous query.
As mentioned in the last comment, this is not a bug.
/*
If we encounter a diagnostics statement (GET DIAGNOSTICS, or e.g.
the old SHOW WARNINGS|ERRORS, or "diagnostics variables" such as
@@warning_count | @@error_count, we'll set some hints so this
information is not lost. DA_KEEP_UNSPECIFIED is used in LEX constructor to
avoid leaving variables uninitialized.
*/
enum enum_keep_diagnostics {
DA_KEEP_NOTHING = 0, /**< keep nothing */
DA_KEEP_DIAGNOSTICS, /**< keep the diagnostics area */
DA_KEEP_COUNTS, /**< keep \@warning_count / \@error_count */
DA_KEEP_PARSE_ERROR, /**< keep diagnostics area after parse error */
DA_KEEP_UNSPECIFIED /**< keep semantics is unspecified */
};
SHOW VARIABLES is not a "diagnostics statement". Thus so in alignment with
the SQL-standard, the diagnostics area will be emptied.
The query "SELECT @@warning_count;" does use the DA_KEEP_COUNTS and will give
the wanted result.
While the query "SHOW VARIABLES LIKE 'warning_count';" is valid, it will not
produce anything useful.
https://dev.mysql.com/doc/refman/5.7/en/diagnostics-area.html
Description: I am not able to get anything else than "=" returned from warning_count. How to repeat: -- case 1 SELECT ABS('a'); -- returns "0" as expected SHOW WARNINGS; -- Warning 1292 Truncated incorrect DOUBLE value: 'a' SHOW VARIABLES LIKE 'warning_count'; -- returns "0" -- case 2 SELECT ABS('a'); -- "0" SHOW VARIABLES LIKE 'warning_count'; -- returns "0" SHOW WARNINGS; -- empty set Suggested fix: I'd expect that in at least case 2 warning_count should be "1". If this is not the case and if both cases are expected behaviour I ask for a clarification/elaboration here: https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_warning_count And I don't think that SHOW WARNINGS should reset warning-count (if this is happening in case 1)