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 F338646970E for ; Tue, 4 Feb 2020 21:50:12 +0300 (MSK) Date: Tue, 4 Feb 2020 21:50:11 +0300 From: Nikita Pettik Message-ID: <20200204185011.GF1049@tarantool.org> References: <20200121111108.GA18881@tarantool.org> <20200130185216.GC26109@atlas> <20200203113519.GA9896@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200203113519.GA9896@tarantool.org> Subject: Re: [Tarantool-discussions] Implicit cast for COMPARISON List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-discussions@dev.tarantool.org On 03 Feb 14:35, Mergen Imeev wrote: > On Thu, Jan 30, 2020 at 09:52:16PM +0300, Konstantin Osipov wrote: > > * Peter Gulutzan [20/01/22 19:47]: > > > Hi, > > > > > > On 2020-01-21 11:09 a.m., Peter Gulutzan wrote: > > > > > > > I think that the proposed change is good. > > > I withdraw that remark. I misunderstood the proposal. > > > > I side with PeterG. > > > > -- > > Konstantin Osipov, Moscow, Russia > > Hi, > > Let me clarify: you think that during comparison it makes sense > that STRING is implicitly converted to numbers? > > If so, then let's think about it. I think we have some questions > to discuss in this case: > 1) I think it makes sense that numeric types can be compared > without any conversion. Do you agree? We have a special function > that implements a comparison between integers and floating point > numbers. If you do not agree with me, then make your suggestion. > 2) STRING can be implicitly cast to a number. In case it can be > cast to INTEGER, it will be INTEGER. In case it can be cast to > DOUBLE, it will be DOUBLE. Do you agree? Does it mean that '1.0' is converted to integer when it is compared with number? > Should we return to this > issue after the implementation of DECIMAL? > 3) Can STRING be implicitly cast to BOOLEAN? No, it can't. > 4) Can STRING be implicitly cast to BINARY? No, it can't > 5) In case STRING cannot be implicitly cast to the type of the > other operand, should we allow implicitly casting the other > operand to STRING? For example, from "'123r' > 124" move to > "'123r' > '124'"? No, we shouldn't. What is more, now comparison operations are not commutative: tarantool> select '123r' = 124 --- - null - 'Type mismatch: can not convert 123r to numeric' ... tarantool> select 124 = '123r' --- - metadata: - name: 124 = '123r' type: boolean rows: - [false] ... Both comparisons should result in error. > 6) Do you agree that only implicit casting from/to STRING is > allowed? I mean that nothing else can be implicitly cast during a > comparison with any other type if one of the types does not > contain the other. What about scalar/any types? > 7) We need to clarify the rules when comparing SCALAR values. I > think we cannot use the Tarantool rules here, as the Tarantool > rules indicate that “100 < '2' == true”, but we decided that > "100 > '2' == true", since '2' implicitly cast to 2. Could you > suggest the rules that we should use here? There's already existing solution: while fetching value from space, we preserve its initial field type. For SCALAR values we may use one rules, for values fetched from INTEGER/STRING fields - apply another ones.