Functionality Added or Changed
The namespace for triggers has changed. Previously, trigger
names had to be unique per table. Now they must be unique within
the schema (database). An implication of this change is that
DROP TRIGGER syntax now uses a
schema name instead of a table name (schema name is optional
and, if omitted, the current schema will be used).
When upgrading from a version of MySQL 5 older than 5.0.10 to
MySQL 5.0.10 or newer, you must drop all triggers and
re-create them or
will not work after the upgrade. A suggested procedure for
doing this is given in
Upgrading from MySQL 4.1 to 5.0.
-P option is available for use with the
ndb_mgmd client. When called with this
option, ndb_mgmd prints all configuration
stdout, then exits.
References: See also Bug #7518.
global system variable.
Triggers can now reference tables by name. See CREATE TRIGGER Syntax, for more information.
It is no longer necessary to issue an explicit
LOCK TABLES for any tables
accessed by a trigger prior to executing any statements that
might invoke the trigger.
Previously, executing a statement that invoked a trigger would
cause problems unless a
TABLES was first issued for any tables accessed by the
trigger. The exact nature of the problem depended upon the MySQL
5.0 release being used: prior to 5.0.3, this resulted in a
crash; from 5.0.3 to 5.0.7, MySQL would issue a warning; in
5.0.9, the server would issue an error.
The bundled version of the
was upgraded to version 5.0.
On Windows, the search path used by MySQL applications for
my.ini now includes
..\my.ini (that is, the application's
parent directory, and hence, the installation directory).
API function for obtaining information about the default
character set of the current connection.
The viewing of triggers and trigger metadata has been enhanced as follows:
A vulnerability in
zlib could result in a
buffer overflow and arbitrary code execution.
(Bug #11844, CVE-2005-2096, CVE-2005-1849)
NDB ignored the
Hostname option in the
default] section of the cluster configuration file.
MySQL Cluster: ndb_mgmd leaked file descriptors. (Bug #11898)
When attempting to drop a table with a broken unique index,
NDB failed to drop the table and
erroneously report that the table was unknown.
Trying to use a greater number of tables than specified by the
caused table corruption such that data nodes could not be
MySQL Cluster: The MySQL Server left core files following shutdown if data nodes had failed. (Bug #11516)
The output of perror
did not display any information about the
MySQL Cluster: Attempting to create or drop tables during a backup would cause the cluster to shut down. (Bug #11942)
In a shared Windows environment, MySQL could not find its
configuration file unless the file was in the
A recent optimizer change caused
DELETE ... WHERE ...
NOT LIKE and
DELETE ... WHERE ... NOT
BETWEEN to not properly identify the rows to be
When used within a subquery,
SUBSTRING() returned an empty
SHOW TABLES failed
to increment the
The server crashed when dropping a trigger that invoked a stored procedure, if the procedure was not yet in the connection-specific stored routine cache. (Bug #11889)
For prepared statements, the SQL parser did not disallow
?” parameter markers
immediately adjacent to other tokens, which could result in
malformed statements in the binary log. (For example,
SELECT * FROM t WHERE? = 1 could become
SELECT * FROM t WHERE0 = 1.)
When two threads competed for the same table, a deadlock could
occur if one thread also had a lock on another table through
LOCK TABLES and the thread was
attempting to remove the table in some manner while the other
thread tried to place locks on both tables.
The server did not compile correctly when using gcc4 on AMD64 platforms. (Bug #12040)
SHOW BINARY LOGS displayed a file
size of 0 for all log files but the current one if the files
were not located in the data directory.
Duplicate trigger names were permitted within a single schema. (Bug #6182)
IP addresses not shown in
command on second ndb_mgmd (or on ndb_mgmd restart).
For a stored procedure defined with
reported the use invoking the procedure, not the user who
INFORMATION_SCHEMA.COLUMNS had some
inaccurate values for some data types.
ORDER BY on a
SELECT from a
VIEW produced unexpected results when
VIEW and underlying table had the same column
name on different columns.
The server did not accept some fully qualified trigger names. (Bug #8758)
Increased the version number of the
libmysqlclient shared library from 14 to 15
because it is binary incompatible with the MySQL 4.1 client
For execution of a stored procedure that refers to a view, changes to the view definition were not seen. The procedure continued to see the old contents of the view. (Bug #6120)
Creating a trigger in one database that references a table in another database was being permitted without generating errors. (Bug #8751)
mysql.proc table was not being created
properly with the proper
utf8 character set
and collation, causing server crashes for stored procedure
operations if the server was using a multibyte character set.
To take advantage of the bug fix,
mysql_fix_privilege_tables should be run to
correct the structure of the
Note that it is necessary to run
mysql_fix_privileges_tables when upgrading
from a previous installation that contains the
mysql.proc table (that is, from a previous
5.0 installation). Otherwise, creating stored procedures might
SELECT ... NOT IN() gave unexpected results
when only static value present between the
MySQL server would crash is a fetch was performed after a
cursors were involved.
The server crashed upon execution of a statement that used a
stored function indirectly (via a view) if the function was not
yet in the connection-specific stored routine cache and the
statement would update a
variable. This fix enables the use of stored routines under
LOCK TABLES without explicitly
mysql.proc table. However, you
mysql.proc in statements that will
combine locking of it with modifications for other tables.
Incorrect column values could be retrieved from views defined
using statements of the form
SELECT * FROM
Aliasing the column names in a
VIEW did not
work when executing a
query on the
With strict SQL mode enabled,
TABLE reported spurious “Invalid default
value” messages for columns that had no
Execution of a prepared statement that invoked a nonexistent or dropped stored routine would crash the server. (Bug #11834)
traditional SQL mode accepted invalid
dates if the date value provided was the result of an implicit
SHOW PROCEDURE/FUNCTION STATUS didn't work
for users with limited access.
In SQL prepared statements, comparisons could fail for values
not equally space-padded. For example,
SELECT 'a' =
'a '; returns 1, but
PREPARE s FROM
'SELECT ?=?'; SET @a = 'a', @b = 'a '; PREPARE s FROM
'SELECT ?=?'; EXECUTE s USING @a, @b; incorrectly
LIKE pattern matching using prefix index didn't return correct result. (Bug #11650)
When invoked within a view,
SUBTIME() returned incorrect
Within a stored procedure that selects from a table, invoking another procedure that requires a write lock for the table caused that procedure to fail with a message that the table was read-locked. (Bug #9565)
For several character sets, MySQL incorrectly converted the
character code for the division sign to the
eucjpms character set.
The C API function
mysql_stmt_reset() did not clear
Labels in stored routines did not work if the character set was
Within a stored procedure, selecting from a table through a view caused subsequent updates to the table to fail with a message that the table was read-locked. (Bug #9597)
Server-side prepared statements failed for columns with a
character set of