----- Original Message -----
Hi Daniel,
On 12/22/2014 03:30 PM, Daniel Black wrote:
----- Original Message -----
Hi, Alexander!
On Dec 22, Alexander Barkov wrote:
Hi Sergei, Kristian,
I'm looking at:
MDEV-7268 Column of table cannot be converted from type 'decimal(0,?)' to type ' 'decimal(10,7)'
This bug cannot be fixed in general case, because the old DECIMAL data type does not write its metadata into the binary log.
I suggest we don't fix replication of old DECIMAL (neither binlogging, nor slave-side).
I think that's reasonable. But then CHECK TABLE ... FOR UPGRADE should issue a warning for old DECIMAL columns.
That would be nice. It took diffing a frm file to suspect it was really old decimal.
Unfortunately there is no an easy way to find the old DECIMAL in all tables of a database. Perhaps INFORMATION_SCHEMA should provide a way to report the real underlying data type.
If its easy, I'm keen. I see anything that breaks because of this less important than not knowing that an old DECIMAL exists.
To find the old DECIMAL in a single table, one can do the following:
1. start mysql like this:
mysql --column-type-info dbname
2. Run "SELECT * FROM t1"
3. See the "Type" column in the metadata printed
Nice, thanks, I hadn't used that option before.
ALTER..MODIFY goes through a different execution chain.
The parser returns the new data type when it sees the keyword "DECIMAL", while the table definition contains the old DECIMAL. So ALTER notices that the data types are actually different and recreates the table.
so ALTER TABLE can convert but RBR can't? Is this because of the lack of metadata?
Right, with SBR it should work without problems.
Thanks for the confirmation and the other work you are putting into this issue. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.