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

Konstantin Osipov kostja at tarantool.org
Wed Jan 9 11:26:40 MSK 2019

* Vladislav Shpilevoy <v.shpilevoy at tarantool.org> [18/12/29 20:46]:

> But there is another reason why we can't pass *.0 as an iterator value -
> our fast comparators (TupleCompare, TupleCompareWithKey) are designed to
> work with only values of same MP_ type. They do not use slow
> tuple_compare_field() which is able to compare double and integer.

If column data type is REAL, *.0 should be allowed. If column data
type is INT, *.0 should be either forbidden or implicitly cast to
INT (afaiu we chose to allow some implicit casts). But this cast,
if it is allowed, should happen before the value reaches the

> Moreover, I think, we should forbid implicit *.0 -> * This is why we
> designed strict typing, isn't it?

Nikita has created a table of implicit cast behaviour by vendor,
and for all cases not explicitly prescribed by the standard we
will have to follow the majority of vendors. If there is no
majority, we'll stick with Oracle behaviour.

> If a table has column int, we should not be able to select it by double
> values without explicit cast, even if implicit is possible without loss.
> For explicit cast users have CAST operator.
> What do you think?

It's not a question of opinion, it's a question of policy.

Our attitude to casts is:

1. Follow the standard.
2. Follow the majority.
3. Follow Oracle.

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