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 AC7626D3F5; Mon, 25 Oct 2021 11:30:13 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AC7626D3F5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1635150613; bh=u//zs8r1KxzS08UHLmQM8N1C6Yf8wCYPrebhqf7CQC0=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Mld82InoYdigR9YiJQAKwtIB7tf4L/vbXpaZFmMX0KFVCODK+5EXSQJ0f1W2/Ljkk UNlRYoFDARlsnJh1NL5jAdcllxWW6ENHM0JxwIdVp3vUroJLch+UYqEdRxZ8gPvLlE X07FHIVVGk9ZcASHHqBywuMqSGM/LRms9m4e8RKc= Received: from smtpng1.i.mail.ru (smtpng1.i.mail.ru [94.100.181.251]) (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 1DBE86D3F5 for ; Mon, 25 Oct 2021 11:30:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1DBE86D3F5 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1mevMw-0005Qz-G1; Mon, 25 Oct 2021 11:30:10 +0300 Date: Mon, 25 Oct 2021 11:30:09 +0300 To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Message-ID: <20211025083009.GD36295@tarantool.org> References: <4308263e-95f4-9c97-f284-a4ff4136ec26@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4308263e-95f4-9c97-f284-a4ff4136ec26@tarantool.org> X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9C7814344C8C501C81DF2D982FCC3642A10B25E0CD3D2314B182A05F538085040ACF35A9A26DE27DDDED4C22DEB706EFB4153C3A4992E09B1B1DB1EF1EA19CC22 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F9D3BE5B596754B8C2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7B8498AC83B273C12EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38BBCA57AF85F7723F2C37FFADE06E4444BD6036F1E86B46AF8CC7F00164DA146DAFE8445B8C89999728AA50765F7900637F924B32C592EA89F389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC8744B801E316CB65FF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8B953A8A48A05D51F175ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A521C9EBC51D9E2BF6D879279329F90F83B334DDF3273EF5F2D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75FA7FF33AA1A4D21C410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D340D3A19269BBEBAAFF308016B59502ABAF1B9FF3808CEFC48BCE9A6A1BF9A636C3F3A6354DF2673F41D7E09C32AA3244C9B5982609A19DF730A7E3F2EB3B5693533C9DC155518937F729B2BEF169E0186 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojPL6H901iH3F+5adbEflvqw== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5DE9A2F26A6CBF40FB9D19C410010F111483D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v1 04/21] sql: refactor LENGTH() function 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: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Thank you for the review! My answer below. On Fri, Oct 15, 2021 at 12:43:33AM +0200, Vladislav Shpilevoy wrote: > Thanks for the patch! > > On 08.10.2021 19:31, imeevma@tarantool.org wrote: > > Part of #4145 > > --- > > src/box/sql/func.c | 55 +++++++++++++--------------------------------- > > 1 file changed, 15 insertions(+), 40 deletions(-) > > > > diff --git a/src/box/sql/func.c b/src/box/sql/func.c > > index e5d763be1..863dbf1c4 100644 > > --- a/src/box/sql/func.c > > +++ b/src/box/sql/func.c > > @@ -833,6 +833,19 @@ func_hex(struct sql_context *ctx, int argc, struct Mem *argv) > > mem_set_str_allocated(ctx->pOut, str, size); > > } > > > > +/** Implementation of the OCTET_LENGTH() function. */ > > +static void > > +func_octet_length(struct sql_context *ctx, int argc, struct Mem *argv) > > Why is the function LENGTH defined as 'octet_length' instead of just 'length'? ANSI defines two functions: CHAR_LENGTH() (with CHARACTER_LENGTH() as the other name) and OCTET_LENGTH(). The first accepts only STRING values and returns the length in characters or length in octets (depending on the USING clause). The second accepts VARBINARY or STRING and returns the length in octets. We have a LENGTH() function that returns the character length if the argument is STRING, and the octet length if the argument is VARBINARY. Since I am planning to introduce the USING clause, I find it better to use the CHAR_LENGTH() and OCTET_LENGTH() implementations for LENGTH() depending on the type of the argument. The func_octet_length() function will be used cases such as this: SELECT char_length(string_value USING OCTETS); At the moment, I have no plans to introduce OCTET_LENGTH().