From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (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 877B34696C3 for ; Fri, 3 Apr 2020 15:47:44 +0300 (MSK) Date: Fri, 3 Apr 2020 12:47:42 +0000 From: Nikita Pettik Message-ID: <20200403124742.GA2993@tarantool.org> References: <10e401d608cf$20ef8970$62ce9c50$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <10e401d608cf$20ef8970$62ce9c50$@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 0/4] session settings fixes List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Timur Safin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org On 02 Apr 12:14, Timur Safin wrote: > I'm late here on this party, but I very much dislike proposed syntax of Patch is not merged, so it's still okay to suggest changes. > SETTING SET configuration_name = value; > > It feels not SQL-ish, and I see no much value introducing new statement > while there is still SET statement available. SET is not available as a separated statements; it's only a part of UPDATE statements syntax. Rolling it back (SETTING SET -> SET) is not a big deal - only one line of parse.y requires patching. As I already said, I'm okay with all variations, whether it is SET, SET SETTING or SETTING SET. > Why we could not simply use something like: > SET box.session.settings.name = value; box.session.settings -- too long prefix. Originally, SET was suggested as a shortcat for normal UPDATE "_session_settings" ... SQL statement. Since it is shortcat, let's keep it short. > ? > > Thanks, > Timur >