The executing code had a safety assertion so that it refused to free Items
that it didn't create. However, there is a case, undefined user variables,
which would put Items into the list to be freed.
Instead, do something that is more risky in expectation that the code will
be refactored soon, as Kostja wants to do: Remove the assertions from
prepare() and execute(). Put one assertion at a higher level, before
stmt->set_params_from_vars(), which may then create new to-be-freed Items .
- bug #11655 "Wrong time is returning from nested selects - maximum time exists
- input and output TIME values were not validated properly in several conversion functions
- bug #20927 "sec_to_time treats big unsigned as signed"
- integer overflows were not checked in several functions. As a result, input values like 2^32 or 3600*2^32 were treated as 0
- BIGINT UNSIGNED values were treated as SIGNED in several functions
- in cases where both input string truncation and out-of-range TIME value occur, only 'truncated incorrect time value' warning was produced
Set a flag when a SHOW command is parsed, and check it in log_slow_statement(). SHOW commands are not counted as slow queries, even if they use table scans.
- Type casting was not consequent, thus when adding a DATE type with
a WEEK interval the result type was DATETIME and not DATE as is the
norm.
- By changing the order of the date internal enumerations the deviant
type casting is resolved (Item_date_add_interval::fix_length_and_dec()
which determines result type for this operation assumes that addition
of any interval with value <= INTERVAL_DAY to date value will result
in date). There are two independant places to change:
interval_names[] and interval_type.
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).
Fix: "mysql --xml" now print NULL values the same way that "mysqldump --xml" does:
<field name="name" xsi:nil="true" />
to distinguish from empty strings:
<field name="name"></field>
and from string "NULL":
<field name="name">NULL</field>
Problem: for character sets having mbmaxlen==2,
any ALTER TABLE changed TEXT column type to MEDIUMTEXT,
due to wrong "internal length to create length" formula.
Fix: removing rounding code introduced in early 4.1 time,
which is not correct anymore.
Adding a multibyte-aware VARCHAR copying function, to put correct column prefix,
taking in account number of characters (instead just limiting on number of bytes).
For example, for a KEY(col(3)) on a UTF8 column when copying the string 'foo bar foo',
we should put only 3 leftmost characters: 'foo'.
9 characters were incorrectly put before this fix.
On an INSERT into an updatable but non-insertable view an error message was
issued stating the view being not updatable. This can lead to a confusion of a
user.
A new error message is introduced. Is is showed when a user tries to insert
into a non-insertable view.
