From: Nikita Pettik <korablev@tarantool.org> To: Mergen Imeev <imeevma@tarantool.org> Cc: tarantool-discussions@dev.tarantool.org Subject: Re: [Tarantool-discussions] Implicit cast for COMPARISON Date: Tue, 4 Feb 2020 21:50:11 +0300 [thread overview] Message-ID: <20200204185011.GF1049@tarantool.org> (raw) In-Reply-To: <20200203113519.GA9896@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 <pgulutzan@ocelot.ca> [20/01/22 19:47]: > > > Hi, > > > > > > On 2020-01-21 11:09 a.m., Peter Gulutzan wrote: > > > <cut> > > > > 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.
next prev parent reply other threads:[~2020-02-04 18:50 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-21 11:11 Mergen Imeev 2020-01-21 18:09 ` Peter Gulutzan 2020-01-22 14:13 ` Mergen Imeev 2020-01-22 14:24 ` Nikita Pettik 2020-01-30 18:51 ` Konstantin Osipov 2020-01-22 16:43 ` Peter Gulutzan 2020-01-30 18:52 ` Konstantin Osipov 2020-02-03 11:35 ` Mergen Imeev 2020-02-03 15:02 ` Konstantin Osipov 2020-02-04 18:50 ` Nikita Pettik [this message] 2020-02-05 2:57 ` Peter Gulutzan 2020-02-07 14:24 ` Nikita Pettik 2020-02-07 14:40 ` Konstantin Osipov 2020-02-07 22:30 ` Peter Gulutzan 2020-02-11 13:32 ` Mergen Imeev 2020-02-05 7:52 ` Mergen Imeev 2020-02-06 12:41 ` Mergen Imeev 2020-02-06 13:09 ` Mergen Imeev
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200204185011.GF1049@tarantool.org \ --to=korablev@tarantool.org \ --cc=imeevma@tarantool.org \ --cc=tarantool-discussions@dev.tarantool.org \ --subject='Re: [Tarantool-discussions] Implicit cast for COMPARISON' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox