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.
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).
The viewing of triggers and trigger metadata has been enhanced as follows:
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.
References: See also Bug #7518.
Triggers can now reference tables by name. See CREATE TRIGGER Syntax, for more information.
The bundled version of the
was upgraded to version 5.0.
API function for obtaining information about the default
character set of the current connection.
global system variable.
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.
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)
MySQL Cluster: ndb_mgmd leaked file descriptors. (Bug #11898)
MySQL Cluster: The MySQL Server left core files following shutdown if data nodes had failed. (Bug #11516)
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
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.
Increased the version number of the
libmysqlclient shared library from 14 to 15
because it is binary incompatible with the MySQL 4.1 client
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)
SELECT ... NOT IN() gave unexpected results
when only static value present between the
A recent optimizer change caused
DELETE ... WHERE ...
NOT LIKE and
DELETE ... WHERE ... NOT
BETWEEN to not properly identify the rows to be
Execution of a prepared statement that invoked a nonexistent or dropped stored routine would crash the server. (Bug #11834)
Incorrect column values could be retrieved from views defined
using statements of the form
SELECT * FROM
When invoked within a view,
SUBTIME() returned incorrect
For several character sets, MySQL incorrectly converted the
character code for the division sign to the
eucjpms character set.
ORDER BY on a
SELECT from a
VIEW produced unexpected results when
VIEW and underlying table had the same column
name on different columns.
SHOW TABLES failed
to increment the
LIKE pattern matching using prefix index didn't return correct result. (Bug #11650)
IP addresses not shown in
command on second ndb_mgmd (or on ndb_mgmd restart).
SHOW PROCEDURE/FUNCTION STATUS didn't work
for users with limited access.
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.
Aliasing the column names in a
VIEW did not
work when executing a
query on the
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
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.)
The C API function
mysql_stmt_reset() did not clear
INFORMATION_SCHEMA.COLUMNS had some
inaccurate values for some data types.
MySQL server would crash is a fetch was performed after a
cursors were involved.
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.
When used within a subquery,
SUBSTRING() returned an empty
With strict SQL mode enabled,
TABLE reported spurious “Invalid default
value” messages for columns that had no
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)
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)
Server-side prepared statements failed for columns with a
character set of
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
The server did not accept some fully qualified trigger names. (Bug #8758)
Creating a trigger in one database that references a table in another database was being permitted without generating errors. (Bug #8751)
For a stored procedure defined with
reported the use invoking the procedure, not the user who
Labels in stored routines did not work if the character set was
Duplicate trigger names were permitted within a single schema. (Bug #6182)
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)
traditional SQL mode accepted invalid
dates if the date value provided was the result of an implicit
In a shared Windows environment, MySQL could not find its
configuration file unless the file was in the