| Bug #36004 | mysql_stmt_prepare resets the list of warnings | ||
|---|---|---|---|
| Submitted: | 11 Apr 2008 19:15 | Modified: | 7 Mar 2010 18:47 |
| Reporter: | Davi Arnaut (OCA) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Errors | Severity: | S3 (Non-critical) |
| Version: | 6.0-BK | OS: | Any |
| Assigned to: | Davi Arnaut | CPU Architecture: | Any |
| Tags: | mysql_stmt_prepare, show warnings, warning_count | ||
[15 Apr 2008 20:30]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/45455 ChangeSet@1.2642, 2008-04-15 17:29:42-03:00, davi@mysql.com +2 -0 Bug#36004 mysql_stmt_prepare resets the list of warnings Although the manual says that "the list of messages is reset for each new statement that uses a table", the list of messages is being unconditionally reset for prepare commands. The solution is to enforce that the prepare command will only reset the message list if the statement being prepared uses a table or a warning is pushed.
[15 Apr 2008 20:52]
Davi Arnaut
Queued to 6.0-runtime
[20 Apr 2008 13:01]
Bugs System
Pushed into 6.0.6-alpha
[25 Apr 2008 17:21]
Paul DuBois
Noted in 6.0.6 changelog. mysql_stmt_prepare() did not reset the list of messages (those messages available via SHOW WARNINGS).
[20 Nov 2009 22:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/91180 2930 Konstantin Osipov 2009-11-21 Backport of: ------------------------------------------------------------ revno: 2597.42.4 committer: davi@mysql.com/endora.local timestamp: Tue 2008-04-15 17:29:42 -0300 message: Bug#36004 mysql_stmt_prepare resets the list of warnings Although the manual says that "the list of messages is reset for each new statement that uses a table", the list of messages is being unconditionally reset for prepare commands. The solution is to enforce that the prepare command will only reset the message list if the statement being prepared uses a table or a warning is pushed. @ tests/mysql_client_test.c Add test case for Bug#36004
[25 Nov 2009 13:32]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (version source revid:alik@sun.com-20091124194633-yc0achgq1ioyqzng) (merge vers: 6.0.14-alpha) (pib:13)
[25 Nov 2009 13:33]
Bugs System
Pushed into 5.6.0-beta (revid:alik@sun.com-20091124193905-3iyzegd75k4givuz) (version source revid:kostja@sun.com-20091120225350-1y7lu75nbpmle4jv) (merge vers: 5.6.0-beta) (pib:13)
[25 Nov 2009 15:42]
Paul DuBois
Noted in 5.6.0 changelog. Already fixed in 6.0.x.
[6 Mar 2010 11:06]
Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100306103849-hha31z2enhh7jwt3) (version source revid:vvaintroub@mysql.com-20091125142014-7asc9sj33gzki0ym) (merge vers: 5.6.0-beta) (pib:16)
[7 Mar 2010 18:47]
Paul DuBois
Moved 5.6.0 changelog entry to 5.5.3.

Description: Although the manual says that "the list of messages is reset for each new statement that uses a table", the list of messages is being reset for COM_STMT_PREPARE (mysql_stmt_prepare) commands. How to repeat: static void test_bug_prepare() { int rc, warning_count= 0; MYSQL_STMT *stmt; const char hello[]= "hello world!"; DBUG_ENTER("test_bug28386"); myheader("test_bug28386"); rc= mysql_query(mysql, "drop table if exists inexistant"); myquery(rc); DIE_UNLESS(mysql_warning_count(mysql) == 1); query_int_variable(mysql, "@@warning_count", &warning_count); DIE_UNLESS(warning_count); stmt= mysql_simple_prepare(mysql, "select 1"); check_stmt(stmt); DIE_UNLESS(mysql_warning_count(mysql) == 0); query_int_variable(mysql, "@@warning_count", &warning_count); DIE_UNLESS(warning_count); rc= mysql_stmt_execute(stmt); check_execute(stmt, rc); DIE_UNLESS(mysql_warning_count(mysql) == 0); query_int_variable(mysql, "@@warning_count", &warning_count); DIE_UNLESS(warning_count); mysql_stmt_close(stmt); DBUG_VOID_RETURN; } Suggested fix: Instead of remove all warnings, the stmt prepare command should only reset the list of warnings if the statement being prepared uses a table. The fix should be something similar to what we already have in mysql_execute_command: /* Reset warning count for each query that uses tables A better approach would be to reset this for any commands that is not a SHOW command or a select that only access local variables, but for now this is probably good enough. Don't reset warnings when executing a stored routine. */ if ((all_tables || !lex->is_single_level_stmt()) && !thd->spcont) mysql_reset_errors(thd, 0);