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 7BA1246970E for ; Wed, 5 Feb 2020 10:52:37 +0300 (MSK) Date: Wed, 5 Feb 2020 10:52:34 +0300 From: Mergen Imeev Message-ID: <20200205075234.GA16634@tarantool.org> References: <20200121111108.GA18881@tarantool.org> <20200130185216.GC26109@atlas> <20200203113519.GA9896@tarantool.org> <20200204185011.GF1049@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200204185011.GF1049@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: Nikita Pettik Cc: tarantool-discussions@dev.tarantool.org On Tue, Feb 04, 2020 at 09:50:11PM +0300, Nikita Pettik wrote: > 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? > No. I meant to apply the current rules. > > 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? > String "if one of the types does not contain the other." means that any scalar type can be cast to SCALAR and any type can be cast to ANY. > > 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. > I think it is confusing. Also, I agree with Peter here.