Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.
The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).
The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.
Version 5.1 does not have this bug (it was fixed by WL 3146).
- Use the "%.*b" format when printing prepared and exeuted prepared statements to the log.
- Add test case to check that also prepared statements end up in the query log
Bug#14346 Prepared statements corrupting general log/server memory
- Use "stmt->query" when logging the newly prepared query instead of "packet"
when calling a SP from C API"
The bug was caused by lack of checks for misuse in mysql_real_query.
A stored procedure always returns at least one result, which is the
status of execution of the procedure itself.
This result, or so-called OK packet, is similar to a result
returned by INSERT/UPDATE/CREATE operations: it contains the overall
status of execution, the number of affected rows and the number of
warnings. The client test program attached to the bug did not read this
result and ivnoked the next query. In turn, libmysql had no check for
such scenario and mysql_real_query was simply trying to send that query
without reading the pending response, thus messing up the communication
protocol.
The fix is to return an error from mysql_real_query when it's called
prior to retrieval of all pending results.
the server's binlog file, might be set to a different directory. This adds a new
"vardir" parameter, which takes the name of the directory as a value, so that the
test_bug17667() test can find the binlog.
When using a parameter bind MYSQL_TYPE_DATE in a prepared statement,
the time part of the MYSQL_TIME buffer was written to zero in
mysql_stmt_execute(). The param_store_date() function in libmysql.c
worked directly on the provided buffer.
Changed to use a copy of the buffer.
After view onening real view db name and table name are placed
into table_list->view_db & table_list->view_name.
Item_field class does not handle these names properly during
intialization of Send_field.
The fix is to use new class 'Item_ident_for_show'
which sets correct view db name and table name for Send_field.
Bug#17667: An attacker has the opportunity to bypass query logging.
This adds a new, local-only printf format specifier to our *printf functions
that allows us to print known-size buffers that must not be interpreted as
NUL-terminated "strings."
It uses this format-specifier to print to the log, thus fixing this
problem.
