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 C6C4446970E for ; Tue, 21 Jan 2020 14:11:14 +0300 (MSK) Date: Tue, 21 Jan 2020 14:11:08 +0300 From: Mergen Imeev Message-ID: <20200121111108.GA18881@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Tarantool-discussions] Implicit cast for COMPARISON List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-discussions@dev.tarantool.org Hi all, I would like once again ask a question about implicit cast for COMPARISON. Currently the chart of implicit cast for COMPARISON looks this way: To BOOL | To INT | To DBL | To STR | To BIN --------------------------------------------------------- >From BOOL | A | - | - | - | - >From INT | - | A | A | A | - >From DBL | - | A | A | A | - >From STR | - | S | S | A | - >From BIN | - | - | - | - | A I suggested to change this chart so that is should look this way: To BOOL | To NUM | To STR | To BIN ----------------------------------------------- >From BOOL | A | - | - | - >From NUM | - | A | - | - >From STR | - | - | A | - >From BIN | - | - | - | A At the moment the only thing that different in these charts is impicit cast from STRING to number and from number to STRING. I asked the Russian community in Telegram about whether to allow this implicit cast for COMPARISON. At the moment, 31 people have voted, and 25 of them have voted for dropping this implicit cast. So, once again I suggest using these rules: 1) The values of numeric types are comparable without any implicit cast. 2) If the type of one of the values contains the type of another value, then they are comparable. 3) In any other cases, the values are not comparable. About "one type contains another type": we can say that INTEGER contains UNSIGNED; NUMBER contains INTEGER, UNSIGNED, DOUBLE; SCALAR contains all available in SQL types. Since all numeric types are comparable, my suggestion means that a value of any type can be compared with a value of type SCALAR. And in this comparison, the same rules will be used as in no-SQL Tarantool. For example, any value of type STRING is greater than any value of type INTEGER. What do you think about this?