From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id A80DA21221 for ; Mon, 8 Jul 2019 09:12:12 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVcUdi-2SZve for ; Mon, 8 Jul 2019 09:12:12 -0400 (EDT) Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 669ED211F1 for ; Mon, 8 Jul 2019 09:12:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: [tarantool-patches] Re: [PATCH v2 1/1] sql: ANSI aliases for LENGTH() From: "n.pettik" In-Reply-To: Date: Mon, 8 Jul 2019 16:12:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB7A2D6-046C-40F6-94DC-F1112E94000C@tarantool.org> References: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Imeev Mergen > src/box/sql/func.c | 3 +++ > test/sql-tap/func3.test.lua | 23 ++++++++++++++++++++++- > 2 files changed, 25 insertions(+), 1 deletion(-) >=20 > diff --git a/src/box/sql/func.c b/src/box/sql/func.c > index 761a3ab..98cad51 100644 > --- a/src/box/sql/func.c > +++ b/src/box/sql/func.c > @@ -1893,6 +1893,9 @@ sqlRegisterBuiltinFunctions(void) > FIELD_TYPE_STRING), > FUNCTION2(length, 1, 0, 0, lengthFunc, SQL_FUNC_LENGTH, > FIELD_TYPE_INTEGER), > + FUNCTION(char_length, 1, 0, 0, lengthFunc, = FIELD_TYPE_INTEGER), > + FUNCTION(character_length, 1, 0, 0, lengthFunc, > + FIELD_TYPE_INTEGER), Please, verify usage of SQL_FUNC_LEGTH flag. I see that it serves to provide certain optimisation, but it is likely to be inapplicable to the current SQL implementation. Hence, I guess we should remove it now and create an issue to resurrect it in the future (if it is = possible at all). lgtm=