Several visible behaviors have changed between MySQL 4.0 and MySQL 4.1 to fix some critical bugs and make MySQL more compatible with the ANSI SQL standard. These changes may affect your applications.
Some of the 4.1 behaviors can be tested in 4.0 before performing a full upgrade to 4.1. We have added to later MySQL 4.0 releases (from 4.0.12 on) a --new startup option for mysqld.
This option gives you the 4.1 behavior for the most critical changes. You can also enable these behaviors for a given client connection with the SET @@new=1 command, or turn them off if they are on with SET @@new=0.
If you believe that some of the 4.1 changes will affect you, we recommend that before upgrading to 4.1, you download the latest MySQL 4.0 version and run it with the --new option by adding the following to your config file:
[mysqld-4.0] new
That way you can test the new behaviors in 4.0 to make sure that your applications work with them. This will help you have a smooth painless transition when you perform a full upgrade to 4.1 later. Doing it the above way will ensure that you don't accidently later run the 4.1 version with the --new option.
The following list describes changes that may affect applications and that you should watch out for when upgrading to version 4.1:
TIMESTAMP is now returned as a string in 'YYYY-MM-DD HH:MM:SS' format. (The --new option can be used from 4.0.12 on to make a 4.0 server behave as 4.1 in this respect.) If you want to have the value returned as a number (like Version 4.0 does) you should add +0 to TIMESTAMP columns when you retrieve them:
mysql> SELECT ts_col + 0 FROM tbl_name;
Display widths for TIMESTAMP columns are no longer supported. For example, if you declare a column as TIMESTAMP(10), the (10) is ignored.
These changes were necessary for SQL standards compliance. In a future version, a further change will be made (backward compatible with this change), allowing the timestamp length to indicate the desired number of digits for fractions of a second.
Binary values such as 0xFFDF now are assumed to be strings instead of numbers. This fixes some problems with character sets where it's convenient to input a string as a binary value. With this change, you should use CAST() if you want to compare binary values numerically as integers:
mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER); -> 0
If you don't use CAST(), a lexical string comparison will be done:
mysql> SELECT 0xFEFF < 0xFF; -> 1
Using binary items in a numeric context or comparing them using the = operator should work as before. (The --new option can be used from 4.0.13 on to make a 4.0 server behave as 4.1 in this respect.)
For functions that produce a DATE, DATETIME, or TIME value, the result returned to the client now is fixed up to have a temporal type. For example, in MySQL 4.1, you get this result:
mysql> SELECT CAST("2001-1-1" as DATETIME); -> '2001-01-01 00:00:00'
In MySQL 4.0, the result is different:
mysql> SELECT CAST("2001-1-1" as DATETIME); -> '2001-01-01'
DEFAULT values no longer can be specified for AUTO_INCREMENT columns. (In 4.0, a DEFAULT value is silently ignored; in 4.1, an error occurs).
LIMIT no longer accept negative arguments. Use 18446744073709551615 instead of -1.
SERIALIZE is no longer a valid mode value for the sql_mode variable. You should use SET TRANSACTION ISOLATION LEVEL SERIALIZABLE instead. SERIALIZE is no longer valid for the --sql-mode option for mysqld, either. Use --transaction-isolation=SERIALIZABLE instead.
All tables and string columns now have a character set. See Charset. Character set information is displayed by SHOW CREATE TABLE and mysqldump. (MySQL versions 4.0.6 and above can read the new dump files; older versions cannot.)
The table definition format used in .frm files has changed slightly in 4.1. MySQL 4.0 versions from 4.0.11 on can read the new .frm format directly, but older versions cannot. If you need to move tables from 4.1 to a version earlier than 4.0.11, you should use mysqldump. See mysqldump.
If you are running multiple servers on the same Windows machine, you should use a different --shared_memory_base_name option on all machines.
The interface to aggregated UDF functions has changed a bit. You must now declare a xxx_clear() function for each aggregate function XXX().
In general, upgrading to 4.1 from an earlier MySQL version involves the following steps:
Check the changes listed earlier in this section to see if there are any that may affect your applications.
Read the 4.1 news items to see what significant new features you can use in 4.1. See News-4.1.x.
If you are running MySQL Server on Windows, please also see Windows upgrading.
Important note: Early alpha Windows distributions for MySQL 4.1 do not contain any installer program. See Windows binary installation for instructions on how to install such a distribution.
If you are using replication, please also see Replication Upgrade for information on upgrading your replication setup.
After upgrading, update the grant tables to generate the new longer Password column that is needed for secure handling of passwords. The procedure uses mysql_fix_privilege_tables and is described in Upgrading-grant-tables.
The password hashing mechanism has changed in 4.1 to provide better security, but this may cause compatibility problems if you still have clients that use the client library from 4.0 or earlier. (It is very likely that you will have 4.0 clients in situations where clients connect from remote hosts that have not yet upgraded to 4.1). The following list indicates some possible upgrade strategies. They represent various tradeoffs between the goal of compatibility with old clients and the goal of security.
Don't upgrade to 4.1. No behavior will change, but you cannot use any of the new features provided by the 4.1 client/server protocol, either. (MySQL 4.1 has an extended client/server protocol that offers such features as prepared statements and multiple result sets.) See C API Prepared statements.
Upgrade to 4.1 and run the mysql_fix_privilege_tables script to widen the Password column in the user table so that it can hold long password hashes. But run the server with the --old-passwords option to provide backward compatibility that allows pre-4.1 clients to continue to connect to their short-hash accounts. Eventually, when all your clients are upgraded to 4.1, you can stop using the --old-passwords server option. You can also change the passwords for your MySQL accounts to use the new more secure format.
Upgrade to 4.1 and run the mysql_fix_privilege_tables script to widen the Password column in the user table. If you know that all clients also have been upgraded to 4.1, don't run the server with the --old-passwords option. Instead, change the passwords on all existing accounts so that they have the new format. A pure-4.1 installation is the most secure.
Further background on password hashing with respect to client authentication and password-changing operations may be found in Password hashing.