MySQL Bugs: #57171: mysql_upgrade not handling old/new DECIMAL conversion

Bug #57171	mysql_upgrade not handling old/new DECIMAL conversion
Submitted:	1 Oct 2010 13:39	Modified:	14 Oct 2010 22:01
Reporter:	Hartmut Holzgraefe	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	>= mysql-5.0	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	mysql_upgrade

Description:
The DECIMAL format changed between MySQL 4.1 and 5.0, when doing a direct upgrade without dump/restore the old column type is kept for already existing tables with DECIMAL columns though.

This is usually not much of an issue unless one really wants to make use of the new high precision features of the newer DECIMAL type, can lead to problems with row based replication though (Bug #57166)

Problem is: the only way to change the column type is by dump/restore or an explicit ALTER TABLE ... CHANGE/MODIFY COLUMN statement, REPAIR or a simple 
ALTER TABLE .. ENGINE=same_engine keeps the old type. 

Also mysql_upgrade does not report such columns in older format and it is not possible to identify such columns using INFORMATION_SCHEMA or any of the tools distributed with the server (AFAICT)

How to repeat:
See bug #57166

Suggested fix:
Let mysql_upgrade change the format of old DECIMAL columns to the "new" 5.0 format, either implicitly or only when requested by a command line option

Setting to Won't fix 
The above mentioned workaround is the documented behaviour for upgrading from 4.1.
See http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-previous-series.html

See Bug#57426 Mark tables containing old DECIMAL data type as corrupt in 5.5.