From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (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 ED3B246970F for ; Wed, 27 Nov 2019 17:03:19 +0300 (MSK) Date: Wed, 27 Nov 2019 17:03:17 +0300 From: Nikita Pettik Message-ID: <20191127140317.GA56049@tarantool.org> References: <20191127105150.GA7232@atlas> <20191127110532.GA16764@tarantool.org> <20191127111030.GB9233@atlas> <20191127112436.GB16940@tarantool.org> <20191127113917.GD9233@atlas> <20191127122138.GB29304@tarantool.org> <20191127130156.GA31045@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191127130156.GA31045@tarantool.org> 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: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy On 27 Nov 16:01, Mergen Imeev wrote: > 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 ; It may sound trite but why not look at other DBs? For instance, PosgtreSQL uses SHOW command, which looks OK personally to me. Or alternatively why can't we simply use _sql_settings:select("default_engine")? In this case SHOW will be purely SQL shortcut for :select(). > 2) Should we remove _vsession_settings from the problem. What is the problem? What are alternatives? > 3) If we move sysview out of the problem, where should we move it. What do you mean by "move sysview out of the problem"? Could you please clarify last two question. > 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 > > >