Re: [Tarantool-patches] [PATCH 4/5] sql: replace control pragmas by SET

[Mergen Imeev <imeevma@tarantool.org>]

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 <setup name>;

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 <imeevma@tarantool.org> wrote:
> 
> > On Wed, Nov 27, 2019 at 02:39:17PM +0300, Konstantin Osipov wrote:
> > > * Mergen Imeev <imeevma@tarantool.org> [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
> >