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 0B6172212C for ; Wed, 9 Jan 2019 03:26:45 -0500 (EST) 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 dcMq1CsRcEMW for ; Wed, 9 Jan 2019 03:26:44 -0500 (EST) 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 turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id B03F321070 for ; Wed, 9 Jan 2019 03:26:42 -0500 (EST) Date: Wed, 9 Jan 2019 11:26:40 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 3/8] sql: remove numeric affinity Message-ID: <20190109082640.GB20509@chai> References: <58b4d75729413f02134c72886ecbc749e510a1d1.1545987214.git.korablev@tarantool.org> <28e6da44-2d1e-87b5-741d-a791750db6c4@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28e6da44-2d1e-87b5-741d-a791750db6c4@tarantool.org> 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 Cc: Nikita Pettik * Vladislav Shpilevoy [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 iterator. > 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