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 EBE79286F5 for ; Thu, 29 Aug 2019 09:27:57 -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 ADl_PvrEwT1x for ; Thu, 29 Aug 2019 09:27:57 -0400 (EDT) Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100]) (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 4C33F286BF for ; Thu, 29 Aug 2019 09:27:57 -0400 (EDT) Date: Thu, 29 Aug 2019 16:27:53 +0300 From: Nikita Pettik Subject: [tarantool-patches] Re: [PATCH] sql: make GREATEST/LEAST built-ins accept at least two args Message-ID: <20190829132749.GA52325@tarantool.org> References: <20190828145525.43365-1-korablev@tarantool.org> <20190829103847.GF22684@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190829103847.GF22684@atlas> 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: Konstantin Osipov Cc: tarantool-patches@freelists.org, kyukhin@tarantool.org On Thu, Aug 29, 2019 at 01:38:47PM +0300, Konstantin Osipov wrote: > * Nikita Pettik [19/08/28 17:58]: > > Before a46b52004 SQL implementation featured min()/max() functions > > overloading: if one argument was passed, then aggregate version would be > > invoked; otherwise - scalar one. We decided to get rid of it and rename > > scalar version to LEAST()/GREATEST() correspondingly. However, assertion > > inside their implementations has been remained: it verifies that number > > of passed arguments is greater than 1. On the other hand, now one can > > pass literally any number of arguments to this function, including one > > (which results in fired mentioned assertion) and zero (which leads to > > NULL dereference in expr.c: these functions are marked with > > SQL_FUNC_NEEDCOLL flag, and as a consequence they are assumed to have at > > least one argument). Firstly, let's place check that number of passed > > arguments more than one. Secondly, let's not assume that functions with > > SQL_FUNC_NEEDCOLL must have any arguments. > > > > Closes #4453 > > If you introduce a new error message, why are you using it in one > place only? It is also used in Kirill's branch where he reworks built-ins. I've aksed him to cherry-pick my commit. See: https://github.com/tarantool/tarantool/commit/f8927cf3d411c88235cf532cfa3d94ee048969f2 > -- > Konstantin Osipov, Moscow, Russia