Functionality added or changed:
Incompatible Change:
Prior to this release, when DATE values were
compared with DATETIME values, the time
portion of the DATETIME value was ignored, or
the comparison could be performed as a string compare. Now a
DATE value is coerced to the
DATETIME type by adding the time portion as
00:00:00. To mimic the old behavior, use the
CAST() function to cause the
comparison operands to be treated as previously. For example:
SELECT .
(Bug#28929)date_col = CAST(NOW()
AS DATE);
Incompatible Change:
INSERT DELAYED is now downgraded to a normal
INSERT if the statement uses functions that
access tables or triggers, or that is called from a function or
a trigger.
This was done to resolve the following interrelated issues:
The server could abort or deadlock for INSERT
DELAYED statements for which another insert was
performed implicitly (for example, via a stored function
that inserted a row).
A trigger using an INSERT DELAYED
caused the error INSERT DELAYED can't be used
with table ... because it is locked with LOCK
TABLES although the target table was not
actually locked.
INSERT DELAYED into a table with a
BEFORE INSERT or AFTER
INSERT trigger gave an incorrect
NEW pseudocolumn value and caused the
server to deadlock or abort.
Bugs fixed:
Security Fix: A malformed password packet in the connection protocol could cause the server to crash. Thanks for Dormando for reporting this bug, and for providing details and a proof of concept. (Bug#28984, CVE-2007-3780)
Security Fix: Use of a view could allow a user to gain update privileges for tables in other databases. (Bug#27878, CVE-2007-3782)
Security Fix:
The requirement of the DROP privilege for
RENAME TABLE was not enforced.
(Bug#27515, CVE-2007-2691)
Security Fix:
If a stored routine was declared using SQL SECURITY
INVOKER, a user who invoked the routine could gain
privileges.
(Bug#27337, CVE-2007-2692)
Security Fix:
CREATE TABLE LIKE did not require any
privileges on the source table. Now it requires the
SELECT privilege.
In addition, CREATE TABLE LIKE was not
isolated from alteration by other connections, which resulted in
various errors and incorrect binary log order when trying to
execute concurrently a CREATE TABLE LIKE
statement and either DDL statements on the source table or DML
or DDL statements on the target table.
(Bug#23667, Bug#25578, CVE-2007-3781)
Incompatible Change:
When mysqldump was run with the
--delete-master-logs option, binary log files
were deleted before it was known that the dump had succeeded,
not after. (The method for removing log files used
RESET MASTER prior to the dump. This also
reset the binary log sequence numbering to
.000001.) Now mysqldump
flushes the logs (which creates a new binary log number with the
next sequence number), performs the dump, and then uses
PURGE MASTER LOGS to remove the log files
older than the new one. This also preserves log numbering
because the new log with the next number is generated and only
the preceding logs are removed. However, this may affect
applications if they rely on the log numbering sequence being
reset.
(Bug#24733)
Incompatible Change:
The use of an ORDER BY or
DISTINCT clause with a query containing a
call to the GROUP_CONCAT()
function caused results from previous queries to be redisplayed
in the current result. The fix for this includes replacing a
BLOB value used internally for sorting with a
VARCHAR. This means that for long results
(more than 65,535 bytes), it is possible for truncation to
occur; if so, an appropriate warning is issued.
(Bug#23856, Bug#28273)
