[Tarantool-patches] [PATCH v5 3/3] box: add SQL settings to _session_settings

[Mergen Imeev]

Hi! Thank you fore review! My answers below.

On Mon, Dec 30, 2019 at 01:21:28PM +0200, Nikita Pettik wrote:
> On 27 Dec 17:05, imeevma at tarantool.org wrote:
> > Part of #4511
> > 
> > @TarantoolBot document
> > Title: _session_settings system space
> > The _session_settings system space used to view or change session
> > settings.
> > 
> > This space uses a new engine. This allows us to create tuples on
> > the fly when the get() or select() methods are called. This
> > engine does not support the insert(), replace(), and delete()
> > methods. The only way to change the setting value is update(),
> > which can only be used with the "=" operation.
> 
> Do you have instruction for developers how to insert to this space
> new values and remove obsolete ones? Sooner or later we will have to
> introduce new SQL settings and clean-up unused.
>  
There is no such instruction for now. I will write an
article in our wiki a bit later.

> > Because space creates a tuple on the fly, it allows us to get a
> > tuple without saving it anywhere. But this means that every time
> > we get a tuple from this system space, it is a new tuple, even if
> > they look the same:
> > 
> > tarantool> s = box.space._session_settings
> > tarantool> name = 'sql_default_engine'
> > tarantool> s:get({name}) == s:get({name})
> > ---
> > - false
> > ...
> > 
> > Currently, this space contains only SQL settings, since the only
> > session settings are SQL settings.
> > 
> > List of currently available session settings:
> > 
> > sql_default_engine
> > sql_defer_foreign_keys
> > sql_full_column_names
> > sql_full_metadata
> > sql_recursive_triggers
> > sql_reverse_unordered_selects
> 
> Is user capable of setting default values for these options?
>  
No, at least for now. Even if user will be able to do this,
the default value of setting is a global setting. At least
until we will be able to differentiate users.

> > Debug build also have debug settings that could be obtained from
> > this sysview:
> > 
> > sql_parser_trace
> > sql_select_trace
> > sql_trace
> > sql_vdbe_addoptrace
> > sql_vdbe_debug
> > sql_vdbe_eqp
> > sql_vdbe_listing
> > sql_vdbe_trace
> > sql_where_trace
> 
> Imho there are too many debug options. We can easily merge
> half of them (where + select traces, vdbe eqp + debug).
> What is more, I think different set of options on debug and
> release builds is quite error prone. Mb it is worth keeping
> debug options all the time, but disallow setting their values
> to true?
>
It is possible, but I don’t think there will be problems,
since there are no numerical identifiers. Still, I do not
think that user should be able to see internal settings.