The world's most popular open source database
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 as shown in this example: SELECT
.
(Bug#28929)date_col = CAST(NOW() AS DATE) FROM
table;
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 BINARY 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)

