[Tarantool-patches] [PATCH v5 3/3] box: add SQL settings to _session_settings
Nikita Pettik
korablev at tarantool.org
Mon Dec 30 16:15:18 MSK 2019
On 30 Dec 15:41, Mergen Imeev wrote:
> Sorry, forgot to answer one question. The answer below.
>
> On Mon, Dec 30, 2019 at 03:38:13PM +0300, Mergen Imeev wrote:
> > 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
> > > >
> > > > Currently, this space contains only SQL settings, since the only
> > > > session settings are SQL settings.
> > > >
> > > > 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).
> I agree, but I suggest to leave this to the next release.
> Should I create an issue?
Why can't you do it right now? Nevertheless they are dubug
options it's not okay to release settings which are fated to
be remove the next day after release.
> > > 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.
More information about the Tarantool-patches
mailing list