Oracle 5.0 Reference Manual page 165

conversions might be needed and the work involved to perform them. Make a copy of your MySQL
instance that contains a full copy of the
your upgrade procedure on this dummy instance to see what actions might be needed so that you can
better evaluate the work involved when performing actual data conversion on your original database
instance.
Several visible behaviors have changed between MySQL 4.1 and MySQL 5.0 to make MySQL more
compatible with standard SQL. These changes may affect your applications.
The following lists describe changes that may affect applications and that you should watch out for
when upgrading from MySQL 4.1 to 5.0.
Server Changes
• Incompatible change: Character set or collation changes may require table indexes to be rebuilt.
In MySQL 5.0, these occurred in version 5.0.48. For details, see
Tables or Indexes Must Be
• Incompatible change:
clause for each column. If a column is created from an expression, the default alias is the expression
text, which can be quite long. As of MySQL 5.0.52, aliases for column names in
statements are checked against the maximum column length of 64 characters (not the maximum
alias length of 256 characters). As a result, views created from the output of
fail if any column alias exceeds 64 characters. This can cause problems for replication or loading
dump files. For additional information and workarounds, see
• Incompatible change: Beginning with MySQL 5.0.42, when a
DATETIME
00:00:00. Previously, the time portion of the
could be performed as a string comparison. To mimic the old behavior, use the
function to cause the comparison operands to be treated as previously. For example:
date_col
• Incompatible change: For
commas were mapped to
from true
0xff
dump and reload any tables that have
tables using
than 5.0.36 to version 5.0.36 or newer.
• Incompatible change. For
MySQL 5.0.15. The pad value for inserts now is
the pad value for retrievals. For details, see
• Incompatible change: As of MySQL 5.0.13,
statement on a transaction timeout. As of MySQL 5.0.32, a new option,
innodb_rollback_on_timeout
transaction if a transaction timeout occurs (the same behavior as in MySQL 4.1).
• Incompatible change: The namespace for triggers changed in MySQL 5.0.10. 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
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
suggested procedure for doing this:
1. Upgrade to MySQL 5.0.10 or later to be able to access trigger information in the
INFORMATION_SCHEMA.TRIGGERS
Rebuilt".
SHOW CREATE VIEW
value, the value is coerced to the
DATE
= CAST(NOW() AS DATE)
ENUM
internally. However, this rendered the commas indistinguishable
0xff
characters in the values. This no longer occurs. However, the fix requires that you
with the current server before upgrading from a version of MySQL 5.0 older
mysqldump
BINARY
DROP TRIGGER
Upgrading MySQL
database, plus all other databases without data. Run
mysql
displays view definitions using an
DATETIME
DATETIME
columns that had enumeration values containing commas, the
columns containing true
ENUM
columns, the pad value and how it is handled has changed as of
rather than space, and there is no stripping of
0x00
Section 11.1.6.2, "The
rolls back only the last
InnoDB
[1249], causes
InnoDB
syntax now uses a schema name instead of a table
will not work after the upgrade. Here is a
DROP TRIGGER
table. (This should work even for pre-5.0.10 triggers.)
145
Section 2.19.3, "Checking Whether
AS alias_name
CREATE VIEW
SHOW CREATE VIEW
Section E.4, "Restrictions on
value is compared with a
DATE
type by adding the time portion as
value was ignored, or the comparison
CAST()
in their values: Dump the
0xff
and
BINARY VARBINARY
--
to abort and roll back the entire
Views".
[948]
Types".