From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.mail.ru (smtp3.mail.ru [94.100.179.58]) (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 AA15A46970F for ; Thu, 28 Nov 2019 02:22:07 +0300 (MSK) 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> From: Vladislav Shpilevoy Message-ID: <73e0d8e6-3bd3-3807-732a-32dfe5790466@tarantool.org> Date: Thu, 28 Nov 2019 00:22:03 +0100 MIME-Version: 1.0 In-Reply-To: <20191127130156.GA31045@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 , Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org On 27/11/2019 14: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 ; Sounds ok. But even more ok - just keep PRAGMAs as they are. > > 2) Should we remove _vsession_settings from the problem. I always vote yes, when a question is whether should we delete some code, drop a system space, etc. > > 3) If we move sysview out of the problem, where should we move it. To /dev/null. Together with all the other SQL. But nobody listens anyway. So we are going to push this space and support it forever.