[tarantool-patches] Re: [PATCH 3/8] sql: remove numeric affinity

Konstantin Osipov kostja at tarantool.org
Sat Dec 29 12:01:03 MSK 2018


* Nikita Pettik <korablev at tarantool.org> [18/12/28 12:36]:

> The only real pitfall is implicit conversion mentioned above.
> What is more, vinyl engine complicates problem since it relies
> on data encoding (i.e. whether it is encoded as MP_INT or MP_FLOAT).
> For instance, if we encode 1.0 as MP_FLOAT during insertion, we won't
> be able to use iterators from Lua, since they implicitly change type of
> 1.0 and pass it to the iterator as MP_INT.  Solution to this problem is
> simple: lets always attempt at encoding floats as ints if conversion
> takes place without loss. This is a straightforward approach, but to
> implement it we need to care about reversed (decoding) situation.

I think the issue is more complicated.

First of all, if SQL column type is INT, Tarantool column type
should be INT, and vinyl/memtx index type should be INT. This
is the first thing to do/ensure and this will remove INT data type
from consideration altogether.

Now, for REAL data type, Tarantool data type should be NUMBER, since in
Tarantool we have no separate data type for REAL, but 
one should *always* use MP_FLOAT/MP_DOUBLE encoding, even for
integer values within this type - to simplify and speed up
comparison functions.


Finally, to Vinyl. It seems it has a bug in a way that it behaves
differently from memtx, and differently depending on whether the
value is in memory or on disk.
In other words, imagine we don't have any data on disk and bloom
filters are not used. Then the value '1' searched by key '1.0'
will be found. Otherwise not. I believe this should be reported as
a separate bug in vinyl.


-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov




More information about the Tarantool-patches mailing list