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 columns in HAVING can reference the GROUP BY and
SELECT columns. There can be "table" prefixes when
referencing these columns. And these "table" prefixes
in HAVING use the table alias if available.
This means that table aliases are subject to the same
storage rules as table names and are dependent on
lower_case_table_names in the same way as the table
names are.
Fixed by :
1. Treating table aliases as table names
and make them lowercase when printing out the SQL
statement for view persistence.
2. Using case insensitive comparison for table
aliases when requested by lower_case_table_names
if running as root
Every start of a server in the test suite raised that warning.
The cause was an unconditionla add of the --user option to the
server command line. Only the "root" user (effective user id == 0)
must use that option.
Added check for effective user id == 0 before adding --user.
Thanks to Magnus Svensson for the patch.
Partition handler fails updating tables with partitioning
based on timestamp field, as it calculates the timestamp field
AFTER it calculates the number of partition of a record.
Fixed by adding timestamp_field->set_time() call and disabling
such consequent calls
wait_condition timeout.
The problem was that the event thread didn't manage to execute
the event in 30 seconds on highly-loaded box. The fix is to
increase timeout.
This is a fix for the test suite.
Merge fix
partition_mgm did not require have_symlink.
Moved the test case to partition_symlink, which
require have_symlink, and should work on both *nix and
Windows
in stored procedure.
The problem was that MySQL used unnecessarily large amounts of
memory if user variables were used as an argument to CONCAT or
CONCAT_WS -- 16M per each user variable used.
Technically, it happened because MySQL used the following
allocation strategy for string functions to avoid multiple
realloc() calls: in the virtual operation fix_length_and_dec()
the attribute max_length was calculated as a sum of max_length
values for each argument.
Although this approach worked well for small (or fixed) data types,
there could be a problem if there as a user variable among
the arguments of a string function -- max_length of the function
would be 16M (as the max_length of a user variable is 16M).
Both CONCAT() and CONCAT_WS() functions suffer from this problem.
The fix is to do not use meta-data for allocating memory.
The following strategy is proposed instead: allocate the exact
length of the result string at the first record, double the amount
of memory allocated when it is required.
No test case for this bug because there is no way to test memory
consumption in a robust way with our test suite.
