From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 C9AB746970F for ; Wed, 27 Nov 2019 16:02:00 +0300 (MSK) Date: Wed, 27 Nov 2019 16:01:56 +0300 From: Mergen Imeev Message-ID: <20191127130156.GA31045@tarantool.org> References: <20191127105150.GA7232@atlas> <20191127110532.GA16764@tarantool.org> <20191127111030.GB9233@atlas> <20191127112436.GB16940@tarantool.org> <20191127113917.GD9233@atlas> <20191127122138.GB29304@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 4/5] sql: replace control pragmas by SET List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy On Wed, Nov 27, 2019 at 03:49:42PM +0300, Konstantin Osipov wrote: > Ok, this goal is nice, but now that it is clear it is a different goal than > fixing pragmas, what about making e.g. box.cfg settings available from all > interfaces? Adding access to global defaults, not just session defaults? Or > plugin settings, like log? Even though the declared aim is to come up with > a general solution, the implementation leaves a lot of questions unanswered. > So, at the end we have the following questions: 1) Should we return the SQL tuning value when SET is used as follows: SET ; 2) Should we remove _vsession_settings from the problem. 3) If we move sysview out of the problem, where should we move it. I have no answers to these questions. I hope Kirill, Vlad, Nikita and Sasha will be able to answer them. > On Wed, Nov 27, 2019, 15:21 Mergen Imeev wrote: > > > On Wed, Nov 27, 2019 at 02:39:17PM +0300, Konstantin Osipov wrote: > > > * Mergen Imeev [19/11/27 14:27]: > > > > > But how are you going to fix it? By making SET statement powerful > > > > > enough to query a value or by making the sysview updatable? > > > > > > > > > Since all settings are saved in a “struct session”, I > > > > think that I will use the same methods PRAGMA used. The > > > > system view reads from current_session(), so SET will > > > > also read from there. > > > > > > OK, so you are going to allow SET to return an existing value, > > > without setting it. Then what is the point of having a view, > > > if you can both get and set the values using SET statement? > > > > > I agree that _vsession_settings can be moved from this > > issue to another. It is here due to historical reasons - > > at first it was called _vsql_settings and served as the > > only way to get SQL setting values. Even now, even if this > > is still the only way to get the values, it can be > > transferred to another issue. If we allow to get the > > setting value using the SET statement, then this is > > definitely worth doing. > > > > However, the basic concept of _vsession_settings is > > slightly different. As I said earlier, it allows you to > > get the current values of the session settings from all > > interfaces. > > > > > -- > > > Konstantin Osipov, Moscow, Russia > >