You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to explicitly mention in the release notes for tarantool-2.1 that floating point SQL types are not planned to be compatible between 2.1 and 2.2 releases.
The reason of that is that in 2.1 we'll set 'number' format for columns of these types, but (likely) will restrict it to 'float32' and 'float64' in 2.2. The change of a format requires data migration and cannot be done automatically, because in 2.1 we have no information to distinguish 'number' columns (created from Lua) from FLOAT/DOUBLE/REAL ones (created from SQL).
Other types planned on 2.1 ( tarantool/tarantool#4019 ) seems to be more or less okay. Maybe it worth also to mention that VARCHAR(N) does not check a string length in 2.1 and we provide no guarantees on a behaviour in 2.2+ for strings that are not fit to the specified limit N.
The text was updated successfully, but these errors were encountered:
We need to explicitly mention in the release notes for tarantool-2.1 that floating point SQL types are not planned to be compatible between 2.1 and 2.2 releases.
The reason of that is that in 2.1 we'll set 'number' format for columns of these types, but (likely) will restrict it to 'float32' and 'float64' in 2.2. The change of a format requires data migration and cannot be done automatically, because in 2.1 we have no information to distinguish 'number' columns (created from Lua) from FLOAT/DOUBLE/REAL ones (created from SQL).
Other types planned on 2.1 ( tarantool/tarantool#4019 ) seems to be more or less okay. Maybe it worth also to mention that VARCHAR(N) does not check a string length in 2.1 and we provide no guarantees on a behaviour in 2.2+ for strings that are not fit to the specified limit N.
The text was updated successfully, but these errors were encountered: