[patches] [PATCH 0/7] iproto: send SQL column meta on SELECT

v.shpilevoy at tarantool.org v.shpilevoy at tarantool.org
Thu Mar 1 18:38:53 MSK 2018



> 1 марта 2018 г., в 18:17, n.pettik <korablev at tarantool.org> написал(а):
> 
> 
>> On 1 Mar 2018, at 16:55, v.shpilevoy at tarantool.org <mailto:v.shpilevoy at tarantool.org> wrote:
>> 
>>> 
>>> I would say it is too gently to silently skip situation when collation is missed.
>>> I can't imagine reason when collation isn't found by name, since AFAIK in SQL every
>>> column features collation (even if it wasn't set, by default it would be "BINARY").
>> 
>> Try to write assert(coll != NULL), and sql-tap/collation.test.lua fails, because BINARY collation in SQL has name, that can not be found in Tarantool.
> 
> Well, you can check collation name before lookup. If it is “BINARY”, then handle situation as you done before.
> Otherwise, add sort of assertion. You can see how it happens in sql.c tarantoolSqlite3MakeIdxParts()
> (I am not saying this solution is better, but it already exists and collation transforming from name to
>  internal struct should be the same everywhere, I guess. Moreover, I think that “BINARY” collation is
>  complete mess and names should be replaced with structs, but it is matter of separate patch.)

Done, but I strongly do not like this clutches and squatting with collation names. They must be all removed and replaced with direct pointer to a collation object.

> But still it is up to you.
> 
> Also, as for the last patch, should we remove 'sqlite3_table_column_metadata()' function? It seems to be unused.

Good catch. Done.

> 
> Anyway, the rest seems to be OK.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20180301/d60de275/attachment.html>


More information about the Tarantool-patches mailing list