The problem is that the commands COM_STMT_CLOSE, COM_STMT_RESET,
COM_STMT_SEND_LONG_DATA weren't being logged to the general log.
The solution is to log the general log the aforementioned commands.
--local-infile=0 checks can be bypassed by sending a FETCH LOCAL FILE response
Add a check for CLIENT_LOCAL_FILES before sending a local file.
Beware, that all binary distributions enable sending of local files and it's up
to the programs which use libmysql to disable it, if they don't use this functionality.
Otherwise they are not safe.
Executing a prepared statement associated with a materialized
cursor yields to the client a metadata packet with wrong table
and database names. The problem was occurring because the server
was sending the the name of the temporary table used by the cursor
instead of the table name of the original table. The same problem
occurs when selecting from views, in which case the table name was
being sent and not the name of the view.
The solution is to fill the list item from the temporary table but
preserving the table and database names of the original fields. This
is achieved by tweaking the Select_materialize to accept a pointer to
the Materialized_cursor class which contains the item list to be filled.
value" error even though the value was correct): a C function in my_getopt.c
was taking bool* in parameter and was called from C++ sql_plugin.cc,
but on some Mac OS X sizeof(bool) is 1 in C and 4 in C++, giving funny
mismatches. Fixed, all other occurences of bool in C are removed, future
ones are blocked by a "C-bool-catcher" in my_global.h (use my_bool).
columns (default datatype value is assigned).
The mysql_update function has been modified to generate
an error when trying to set a NOT NULL field to NULL rather than a warning
in the set_field_to_null_with_conversions function.
server status wasn't properly sent to the client after the error
by the embedded server. Wasn't noticed before as one usually stopped
retrieving results after he gets an error.
insert ... select.
The 5.0 manual page for mysql_insert_id() does not mention anything
about INSERT ... SELECT, though its current behavior is incosistent
with what the manual says about the plain INSERT.
Fixed by changing the AUTO_INCREMENT and mysql_insert_id() handling
logic in INSERT ... SELECT to be consistent with the INSERT behavior,
the manual, and the changes in 5.1 introduced by WL3146:
- mysql_insert_id() now returns the first automatically generated
AUTO_INCREMENT value that was successfully inserted by INSERT ... SELECT
- if an INSERT ... SELECT statement is executed, and no automatically
generated value is successfully inserted, mysql_insert_id() now returns
the ID of the last inserted row.
only on some occasions
Referencing an element from the SELECT list in a WHERE
clause is not permitted. The namespace of the WHERE
clause is the table columns only. This was not enforced
correctly when resolving outer references in sub-queries.
Fixed by not allowing references to aliases in a
sub-query in WHERE.
crashes.
MySQL distributions contain a number of programs that are used only by
the MySQL test suite internally, i.e. they are not indended to be
invoked directly by a user. As a result, such programs are not
documented, do not have any built-in help or proper error reporting,
which may confuse users.
This patch fixes the problem with the following changes:
- mytest, libmysqltest and all references to them were removed from the
distribution since they are not used anymore
- bug25714 now displays an error message when run with incorrect
arguments or with the --help option
- mysql_client_test now does not call abort() in case of errors,
instead it does a clean exit() with a proper error status.
command and reported to a client.
The fact that a timestamp field will be set to NO on UPDATE wasn't shown
by the SHOW COMMAND and reported to a client through connectors. This led to
problems in the ODBC connector and might lead to a user confusion.
A new filed flag called ON_UPDATE_NOW_FLAG is added.
Constructors of the Field_timestamp set it when a field should be set to NOW
on UPDATE.
The get_schema_column_record function now reports whether a timestamp field
will be set to NOW on UPDATE.
The problem is that when copying the supplied username and
database, no bounds checking is performed on the fixed-length
buffer. A sufficiently large (> 512) user string can easily
cause stack corruption. Since this API can be used from PHP
and other programs, this is a serious problem.
The solution is to increase the buffer size to the accepted
size in similar functions and perform bounds checking when
copying the username and database.
