From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 3033846970F for ; Wed, 27 Nov 2019 15:49:55 +0300 (MSK) Received: by mail-ed1-f66.google.com with SMTP id cy15so11979954edb.4 for ; Wed, 27 Nov 2019 04:49:55 -0800 (PST) MIME-Version: 1.0 References: <20191127105150.GA7232@atlas> <20191127110532.GA16764@tarantool.org> <20191127111030.GB9233@atlas> <20191127112436.GB16940@tarantool.org> <20191127113917.GD9233@atlas> <20191127122138.GB29304@tarantool.org> In-Reply-To: <20191127122138.GB29304@tarantool.org> From: Konstantin Osipov Date: Wed, 27 Nov 2019 15:49:42 +0300 Message-ID: Content-Type: multipart/alternative; boundary="000000000000eada560598536ef7" 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: Imeev Mergen Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy --000000000000eada560598536ef7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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= . 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 =E2=80=9Cstruct session=E2=80=9D, 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 > --000000000000eada560598536ef7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, this goal is nice, but now that it is clear it is a d= ifferent goal than fixing pragmas, what about making e.g. box.cfg settings = available from all interfaces? Adding access to global defaults, not just s= ession defaults? Or plugin settings, like log? Even though the declared=C2= =A0 aim is to come up with a general solution, the implementation leaves a = lot of questions unanswered.

On Wed, Nov 27, 2019, 15:21 Mergen Imeev <= imeevma@tarantool.org> wrot= e:
On Wed, Nov 27, 2019 at 02:39:17= PM +0300, Konstantin Osipov wrote:
> * Mergen Imeev <imeevma@tarantool.org> [19/11/27 14:27]:<= br> > > > But how are you going to fix it? By making SET statement pow= erful
> > > enough to query a value or by making the sysview updatable?<= br> > > >
> > Since all settings are saved in a =E2=80=9Cstruct session=E2=80= =9D, 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
--000000000000eada560598536ef7--