[tarantool-patches] Re: [PATCH] sql: fix type in meta for unsigned binding

Konstantin Osipov kostja at tarantool.org
Wed Jul 24 21:23:07 MSK 2019


* n.pettik <korablev at tarantool.org> [19/07/24 20:45]:
> 
> 
> > On 24 Jul 2019, at 20:10, Konstantin Osipov <kostja at tarantool.org> wrote:
> > 
> > * Nikita Pettik <korablev at tarantool.org> [19/07/24 19:59]:
> >> It was decided that for all integer literals we would return "INTEGER"
> >> type, not "UNSIGNED". Accidentally, after substitution of unsigned
> >> binding value type was set to "UNSIGNED". Let's fix that and set
> >> "INTEGER" type.
> > 
> > the patch is lgtm but I'm not sure it covers all cases.
> > 
> > I've seen a lot of unsigned inthe tests.
> 
> I see only one more unsigned appearance:
> 
> box.execute("SELECT CAST('123' AS UNSIGNED);")
> ---
> - metadata:
>   - name: CAST('123' AS UNSIGNED)
>     type: unsigned
>   rows:
>   - [123]
>> 
> But I guess in this case user would be less surprised
> if one saw unsigned type than integer.

This cast is very good. Very, very, good :) This cast is even better:

tarantool> select cast(NULL as unsigned)
{
  metadata = {
    {
      name = "cast(NULL as unsigned)",
      type = "unsigned"
    }
  },
  rows = {
    "[null]"
  }
}

This cast is what static types were all about. Not about a
separate compile-time pass with static analysis - it's an
implementation detail, and I'm not sure we'll ever need it,
it is merely a performance optimization. 

-- 
Konstantin Osipov, Moscow, Russia




More information about the Tarantool-patches mailing list