From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 590C82C9B2 for ; Thu, 25 Apr 2019 07:07:59 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8M4INbuPkQ6 for ; Thu, 25 Apr 2019 07:07:59 -0400 (EDT) Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 128E82C9B1 for ; Thu, 25 Apr 2019 07:07:58 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v1 1/1] sql: invalid integer type in arithmetic operations References: <72941eba60647c98f4559cbd0c862bade990d761.1556120090.git.kshcherbatov@tarantool.org> <0929e575-2d28-7cd0-36bc-0a1bf1af76fe@tarantool.org> <04E0C86F-84E5-400F-ACE0-80FD6799E4E3@tarantool.org> <20190425104956.GI29257@atlas> <20190425105237.GA2297@atlas> From: Kirill Shcherbatov Message-ID: Date: Thu, 25 Apr 2019 14:07:56 +0300 MIME-Version: 1.0 In-Reply-To: <20190425105237.GA2297@atlas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org, Konstantin Osipov Cc: Vladislav Shpilevoy >> SQL *is* server. Please begin by having a comment containing a >> table for integer type arithmetics, something like this: >> >> Plus operation: >> -------------- >> >> integer float >> >> integer integer float >> float float float >> >> It's best to implement such table in the source code too, and not >> have complicated branching. > > Re UNSIGNED type itself: > > once you have a proper table for type arithmetics, it will be easy > to understand what the result of unsigned + unsigned should be. > Most likely it should be unsigned, not a number. Exactly this logic is already on master branch (but only with few sequential ifs, not a table).