Re: [Tarantool-patches] [PATCH v4 06/16] sql: introduce mem_append()

[Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Hi! Thanks for the fixes!

>>> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c
>>> index 079083fa1..b8ead8f41 100644
>>> --- a/src/box/sql/mem.c
>>> +++ b/src/box/sql/mem.c
>>> @@ -1925,6 +1925,27 @@ mem_move(struct Mem *to, struct Mem *from)
>>>  	from->zMalloc = NULL;
>>>  }
>>>  
>>> +int
>>> +mem_append(struct Mem *mem, const char *value, uint32_t len)
>>> +{
>>> +	assert((mem->type & (MEM_TYPE_BIN | MEM_TYPE_STR)) != 0);
>>> +	if (len == 0)
>>> +		return 0;
>>> +	int new_size = mem->n + len;
>>> +	if (((mem->flags & (MEM_Static | MEM_Dyn | MEM_Ephem)) != 0) ||
>>> +	    mem->szMalloc < new_size) {
>>> +		/*
>>> +		 * Force exponential buffer size growth to avoid having to call
>>> +		 * this routine too often.
>>> +		 */
>>> +		if (sqlVdbeMemGrow(mem, new_size + mem->n, 1) != 0)
>>
>> Looks like you could call sqlVdbeMemGrow() without all these checks
>> above. The grow function does them already.
>>
> True, fixed. There is a case where the behavior will be different - I
> mean the case where new_size < szMalloc and new_size + n > szMalloc,
> but that doesn't seem to be a very common case.

Wait, this does not look correct either. I thought sqlVdbeMemGrow()
does the exponential grow. But if it does not, we need to either patch
it, or keep some checks above. The 'standard' way is to grow only when
necessary, but at least x2. How this new way works I can't tell. It
might be worse. You will always have unused free space. Lets either
stick to the old way or patch the grow function.