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

[Nikita Pettik <korablev@tarantool.org>]

On 27 Dec 17:05, imeevma@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.
 
> 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?
 
> 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?