[tarantool-patches] Re: [PATCH v2 2/2] sql: fix error in case ARRAY/MAP converted to SCALAR

[n.pettik]

> 
> New patch:
> 
> From 5dde6f6398ca9845c3a17173b9e9625bc1b20d32 Mon Sep 17 00:00:00 2001
> From: Mergen Imeev <imeevma at gmail.com>
> Date: Mon, 22 Jul 2019 12:54:34 +0300
> Subject: [PATCH] sql: fix error in case ARRAY/MAP converted to SCALAR
> 
> Since ARRAY and MAP cannot be converted to a scalar, this
> operation should throw an error. But when the error was throws
> from SQL, the error was unreadable. The reason for this is that
> the given array or map was not correctly converted to a string.
> This patch fixes the problem by converting ARRAY or MAP to their
> string representation.
> For example:
> 
> box.execute('CREATE TABLE t1(i INT PRIMARY KEY, a SCALAR);')
> format = {}
> format[1] = {type = 'integer', name = 'I'}
> format[2] = {type = 'array', name = 'A'}
> s = box.schema.space.create('T2', {format=format})
> i = s:create_index('ii')
> s:insert({1, {1,2,3}})
> box.execute('INSERT INTO t1 SELECT * FROM t2;')
> 
> Should return:
> - error: 'Type mismatch: can not convert [1, 2, 3] to scalar'
> 
> Follow-up #4189

Fixed a bit commit message:

    sql: make valueToText() operate on MAP/ARRAY values
    
    Since ARRAY and MAP cannot be converted to SCALAR type, this operation
    should throw an error. But when the error is raised in SQL, it is
    displayed in unreadable form. The reason for this is that the given
    array or map is not correctly converted to a string. This patch fixes
    the problem by converting ARRAY or MAP to their string representation.
    For example:
    
    box.execute('CREATE TABLE t1(i INT PRIMARY KEY, a SCALAR);')
    format = {}
    format[1] = {type = 'integer', name = 'I'}
    format[2] = {type = 'array', name = 'A'}
    s = box.schema.space.create('T2', {format=format})
    i = s:create_index('ii')
    s:insert({1, {1,2,3}})
    box.execute('INSERT INTO t1 SELECT * FROM t2;')
    
    Should return:
    - error: 'Type mismatch: can not convert [1, 2, 3] to scalar'
    
    Follow-up #4189

> diff --git a/src/box/sql/vdbemem.c b/src/box/sql/vdbemem.c
> index 847a6b0..8bea46b 100644
> --- a/src/box/sql/vdbemem.c
> +++ b/src/box/sql/vdbemem.c
> @@ -1135,6 +1135,19 @@ valueToText(sql_value * pVal)
> {
> 	assert(pVal != 0);
> 	assert((pVal->flags & (MEM_Null)) == 0);
> +	if ((pVal->flags & MEM_Subtype) != 0 &&
> +	    pVal->subtype == SQL_SUBTYPE_MSGPACK) {
> +		const char *value = mp_str(pVal->z);
> +		size_t len = strlen(value) + 1;
> +		char *result = region_alloc(&fiber()->gc, len);
> +		if (result == NULL) {
> +			diag_set(OutOfMemory, len, "region_alloc", "result");
> +			sqlOomFault(sql_get());
> +			return NULL;
> +		}
> +		memcpy(result, value, len);
> +		return result;

That’s not what we need IMHO. Firstly, for all other memory types                  
valueToText() function returns pVal->z, i.e. this function firstly                 
converts value to string and then returns it.  Secondly, we don’t track            
value allocated on region: obviously if it is used after transaction               
commitment, it will lead to use-after-free bug. I can’t say whether this           
scenario is possible looking only on code.  You should rather patch                
sqlVdbeMemStringify: reserve memory using malloc, memcpy string to mem,            
change type of memory to MEM_Str. So that make it work with ARRAY and              
MAP types in the same way as with other types.