[tarantool-patches] Re: [PATCH 3/8] sql: remove numeric affinity

[n.pettik]

>>>>>> diff --git a/src/box/sql.c b/src/box/sql.c
>>>>>> index a06c50dca..a498cd8fe 100644
>>>>>> --- a/src/box/sql.c
>>>>>> +++ b/src/box/sql.c
>>>>>> @@ -376,14 +376,18 @@ sql_ephemeral_space_create(uint32_t field_count, struct sql_key_info *key_info)
>>>>>> for (uint32_t i = 0; i < field_count; ++i) {
>>>>>> struct key_part_def *part = &ephemer_key_parts[i];
>>>>>> part->fieldno = i;
>>>>>> -part->type = FIELD_TYPE_SCALAR;
>>>>>> part->nullable_action = ON_CONFLICT_ACTION_NONE;
>>>>>> part->is_nullable = true;
>>>>>> part->sort_order = SORT_ORDER_ASC;
>>>>>> -if (def != NULL && i < def->part_count)
>>>>>> +if (def != NULL && i < def->part_count) {
>>>>>> +assert(def->parts[i].type < field_type_MAX);
>>>>>> +part->type = def->parts[i].type != FIELD_TYPE_ANY ?
>>>>>> +    def->parts[i].type : FIELD_TYPE_SCALAR;
>>>>>> part->coll_id = def->parts[i].coll_id;
>>>>> 
>>>>> 1. How can key_part have FIELD_TYPE_ANY? We have no comparators for ANY
>>>>> type, it is impossible, isn't it?
>>>> We don’t, and that is why I replace ANY with SCALAR.
>>> 
>>> No, you still check for "def->parts[i].type != FIELD_TYPE_ANY", and I
>>> can not understand how is it possible. struct key_def can not have
>>> FIELD_TYPE_ANY in its parts.
>> Now this problem is fixed in the next patches.
>> In this one it can’t be fixed with ease.
> 
> What a problem can not be fixed? I did this:
> 
> diff --git a/src/box/sql.c b/src/box/sql.c
> index 530ec2384..f53600837 100644
> --- a/src/box/sql.c
> +++ b/src/box/sql.c
> @@ -387,8 +387,7 @@ sql_ephemeral_space_create(uint32_t field_count, struct sql_key_info *key_info)
> 		part->sort_order = SORT_ORDER_ASC;
> 		if (def != NULL && i < def->part_count) {
> 			assert(def->parts[i].type < field_type_MAX);
> -			part->type = def->parts[i].type != FIELD_TYPE_ANY ?
> -				     def->parts[i].type : FIELD_TYPE_SCALAR;
> +			part->type = def->parts[i].type;
> 			part->coll_id = def->parts[i].coll_id;
> 		} else {
> 			part->coll_id = COLL_NONE;
> 
> And no test failed. This is because, as I said, key_part.type
> is never ever can be ANY. I was not talking above about ANY
> removal from all places, but from this particular one. And here
> we can be sure, that key_part.type != FIELD_TYPE_ANY always.
> 
> Please, apply this.

Ok. I've understood that it can't be of type ANY due to
the fact that sql_affinity_to_field_type (which is used to init sql_key_info)
never returns ANY and default value is SCALAR.

Applied.