From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id B2675445320 for ; Mon, 6 Jul 2020 16:52:25 +0300 (MSK) From: Mergen Imeev Message-ID: <2a8578c7-10f5-fd38-409e-4e996f07b865@tarantool.org> Date: Mon, 6 Jul 2020 16:52:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: [Tarantool-discussions] Check implicit cast between strings and numbers List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-discussions@dev.tarantool.org, Peter Gulutzan , Nikita Pettik , Vladislav Shpilevoy , tsafin@tarantool.org Hi, Peter, could you please take a look at my branch and say if something is wrong with the implicit casts between strings and numerics. I mean, there shouldn't be any. Branch: imeevma/gh-3809-disallow-imlicit-cast-from-string-to-nums There should be no implicit casts for assignment after this patch, except for the following: 1) Any type can be implicitly cast to ANY. 2) Any scalar type can be implicitly cast to SCALAR. 3) Any numeric type can be implicitly cast to NUMBER. 4) In some cases, numbers can be implicitly converted to another number type. The rules can be seen in the commit message of the patches. For comparison, we say that any numbers can be compared with each other. However, you may find some cases where the result is not what it should be. This will be fixed in another issue. Also, comparison with SCALAR does not work correctly. This will also be fixed later after we decide how this should work.