From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 730446BD0D; Sun, 11 Apr 2021 21:11:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 730446BD0D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1618164717; bh=GOiyFd0AM45C2DYcuOE1IMfCidrcXPARxxvMw5oRncs=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=TSPwOgyFOxIYVxN6SM87cFT67KfMeELXs3YDkwYUAGv49ucKLuICLKI8goTASsGBr EL0UPYrmXsIF7v97JOuYuQxMJwSIvOPuHZzCLZoteFbl4rlMynsPCPVTifhfOaBbAc KBM8/U7vIHdoadcxnb1H6jOdrQt1X5Ov5LF0d7/s= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4B0D16BD0C for ; Sun, 11 Apr 2021 21:11:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 4B0D16BD0C Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lVeYt-0003C6-5k; Sun, 11 Apr 2021 21:11:55 +0300 To: imeevma@tarantool.org, tsafin@tarantool.org Cc: tarantool-patches@dev.tarantool.org References: Message-ID: Date: Sun, 11 Apr 2021 20:11:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD92FFCB8E6708E7480EBD5CA77A668ECB87DA2124B0A8E6609182A05F538085040F8804967C55036ED1F98EDDD1D6EEE187E9DA1C31007521867E1CAF613438D56 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F2393C4755A27B53EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006373BFF7CCD9F2968778638F802B75D45FF914D58D5BE9E6BC1A93B80C6DEB9DEE97C6FB206A91F05B2EB5EDA3D9FCC91AA4AF64BBEF56AF8B8C247B71DA8F7637ED2E47CDBA5A96583C09775C1D3CA48CFE478A468B35FE767117882F4460429724CE54428C33FAD30A8DF7F3B2552694AC26CFBAC0749D213D2E47CDBA5A9658378DA827A17800CE7ABB305BD10C6E5099FA2833FD35BB23DF004C906525384302BEBFE083D3B9BA73A03B725D353964B0B7D0EA88DDEDAC722CA9DD8327EE4930A3850AC1BE2E73542F54486E6D6388DC4224003CC83647689D4C264860C145E X-C1DE0DAB: 0D63561A33F958A50B55B870EBEEE3C64395D7AFCD8D7429F668132D984D34B5D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D343D1F112031EF3D62443BC7030C03D01977BB665F13B3EC60180C3968087C5CC1E9F8D26CBB90DCD81D7E09C32AA3244C58B2F311207879AD51F6B81BD47625BE259227199D06760AFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyKKJYJ15DtJjTmoWDwvE7w== X-Mailru-Sender: 689FA8AB762F73936BC43F508A0638227794925586BCDBF0F4EF93D9C3E3117E3841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v5 18/52] sql: introduce mem_concat() X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Good job on the patch! See 2 comments below. On 09.04.2021 19:57, Mergen Imeev via Tarantool-patches wrote: > This patch introduces mem_concat(). Function mem_concat() concatenates > values from two MEMs in case these values are strings or binaries and > writes the result to the third MEM. > > Part of #5818 > --- > src/box/sql/mem.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++ > src/box/sql/mem.h | 8 ++++++ > src/box/sql/vdbe.c | 50 ++---------------------------------- > 3 files changed, 74 insertions(+), 48 deletions(-) > > diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c > index b417c1007..2d76ef88d 100644 > --- a/src/box/sql/mem.c > +++ b/src/box/sql/mem.c > @@ -326,6 +326,70 @@ mem_move(struct Mem *to, struct Mem *from) > return 0; > } > > +static bool > +is_result_null(const struct Mem *a, const struct Mem *b, struct Mem *result, > + enum field_type type) 1. Functions called 'is_*' never should change anything. Another question is why do you even need it? It is used in a single place, where it could be just inlined. And is not used in a place, where it could be applied. > +{ > + mem_clear(result); > + result->field_type = type; > + return (((a->flags | b->flags) & MEM_Null) != 0); > +} > + > +int > +mem_concat(struct Mem *a, struct Mem *b, struct Mem *result) > +{ > + assert(result != b); > + if (a != result) { > + if (is_result_null(a, b, result, FIELD_TYPE_STRING)) > + return 0; > + } else { > + if (((a->flags | b->flags) & MEM_Null) != 0) { > + mem_clear(a); > + result->field_type = FIELD_TYPE_STRING; > + return 0; > + } > + } > + > + /* Concatenation operation can be applied only to strings and blobs. */ > + if ((b->flags & (MEM_Str | MEM_Blob)) == 0) { > + diag_set(ClientError, ER_INCONSISTENT_TYPES, > + "text or varbinary", mem_type_to_str(b)); > + return -1; > + } > + if ((a->flags & (MEM_Str | MEM_Blob)) == 0) { > + diag_set(ClientError, ER_INCONSISTENT_TYPES, > + "text or varbinary", mem_type_to_str(a)); > + return -1; > + } > + > + /* Moreover, both operands must be of the same type. */ > + if ((b->flags & MEM_Str) != (a->flags & MEM_Str)) { > + diag_set(ClientError, ER_INCONSISTENT_TYPES, > + mem_type_to_str(a), mem_type_to_str(b)); > + return -1; > + } > + > + if (ExpandBlob(a) != 0 || ExpandBlob(b) != 0) > + return -1; > + > + uint32_t size = a->n + b->n; > + if ((int)size > sql_get()->aLimit[SQL_LIMIT_LENGTH]) { > + diag_set(ClientError, ER_SQL_EXECUTE, "string or blob too big"); > + return -1; > + } > + if (sqlVdbeMemGrow(result, size, result == a) != 0) > + return -1; > + > + result->flags = a->flags & (MEM_Str | MEM_Blob); 2. Why isn't result cleared? What if it was an Agg, or Frame? I see before your patch they called vdbe_prepare_null_out(), which cleared the mem. > + if ((result->flags & MEM_Blob) != 0) > + result->field_type = FIELD_TYPE_VARBINARY; > + if (result != a) > + memcpy(result->z, a->z, a->n); > + memcpy(&result->z[a->n], b->z, b->n); > + result->n = size; > + return 0; > +}