Re: [Tarantool-discussions] Implicit cast for COMPARISON

[Mergen Imeev <imeevma@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 <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?
> 
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.