[Tarantool-discussions] Implicit cast for COMPARISON

[Nikita Pettik]

On 03 Feb 14:35, Mergen Imeev wrote:
> On Thu, Jan 30, 2020 at 09:52:16PM +0300, Konstantin Osipov wrote:
> > * Peter Gulutzan <pgulutzan at 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.