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

[Nikita Pettik]

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

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