Re: [Tarantool-discussions] Implicit cast for COMPARISON

[Mergen Imeev <imeevma@tarantool.org>]

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? Should we return to this
issue after the implementation of DECIMAL?
3) Can STRING be implicitly cast to BOOLEAN?
4) Can STRING be implicitly cast to BINARY?
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'"?
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.
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?