This was split off from WL#2934. Currently our manual states that: "Using FLOAT might give you some unexpected problems because all calculations in MySQL are done with double precision." http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html While that is true, it may result in some really annoying side effects, see BUG#4485 for examples. The reason for them is exactly that we process float numbers as double ones. Taking an example from BUG#4485, "1.1" (decimal base) is an irrational number in the binary base. It's binary representation in the double-precision IEEE 754 format: mantissa = (1.)0001100110011001100110011001100110011001100110011010, exp = 0 While the same number in the single-precision IEEE 754 format is: mantissa = (1.)00011001100110011001101, exp = 0 Assigning the above (float) value to a double variable will result in the following number: mantissa = (1.)0001100110011001100110100000000000000000000000000000, exp = 0 As seen, we cannot rely on (double)(float)1.1 to have the same properties (including decimal representation) as (double)1.1, because these are actually different numbers. So in order to fix BUG#4485 we need a way to handle float numbers separately from double ones within the server. This implies implementing Field::store(float), Field::val_float(), String::set(float), changing all related code to not explicitly case float values to the double type, etc. Kostja notes: perhaps its time to encapsulate store/get logic in a separate class, separate from items. What is the reason to have val_float() and val_str(), instead of just having a single virtual val()?