Re: [Tarantool-discussions] [Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET

[Sergey Ostanevich <sergos@tarantool.org>]

Hi!

I believe it can be a missing point: the system space described actually
contains no data at no time. On SELECT from this space a tuple is filled
from the session settings and on UPDATE corresponding setting will be
set in session structure and no data will be present in the space 
thereafter.

Given that - the space will be the same for all sessions, but since it 
contains no data there will be no cross-session interaction.

Regards,
Sergos

On 06 Dec 16:50, Mergen Imeev wrote:
> 
> Hello Kirill!
> 
> Below you can see my idea of solving the problem. Also,
> after that I will answer your questions.
> 
> In the last discussion, we decided to solve the problem more
> globally: we are going to create a way to change session settings
> that can be used from any interface. So, here are the requirements
> for this method:
> 1) All settings must be in the system space or system view.
> 2) We should be able to SELECT from this space.
> 3) We should be able to UPDATE data in this space. INSERT, DELETE
> and REPLACE cannot be used on this space.
> 4) This space should not affect performance.
> 5) This space should not be involved in transactions.
> 6) We should be able to change the settings on master and on
> replica.
> 7) Space does not have to be persistent.
> 
> To fulfill these requirements, I decided to create and use a new
> engine. This engine will only be used for this space. The format
> of the space will be {{name = 'name', type = 'string'},
> {name = 'value', type = 'any'}}. The space will be temporary.
> 
> When the user selects a tuple from space, the space will create a
> new tuple on the fly. The space itself will be empty, so do not
> worry about performance degradation. On UPDATE, the space will
> change the session settings.
> 
> After we create the space, we can simply remove the control
> pragmas. To change a setting from SQL we just need to
> update value in the space using UPDATE statement.
> 
> 
> On Fri, Dec 06, 2019 at 02:37:11PM +0300, Kirill Yukhin wrote:
> > Hello Mergen!
> > 
> > On 07 ноя 13:36, imeevma@tarantool.org wrote:
> > > The main goal of this set of patches is to replace control pragmas
> > > with the SET operator. Control pragmas are those that change SQL
> > > settings. Along with this, we will allow to see SQL session-local
> > > settings in unified way.
> > > 
> > > https://github.com/tarantool/tarantool/issues/4511
> > > https://github.com/tarantool/tarantool/tree/imeevma/gh-4511-pragma-replaced-by-set
> > 
> > We have at least two mail threads with discussions of how
> > this will be working (PRAGMA and SET keywords).
> > 
> > We have couple of verbal discussions, could you please
> > post approach we developed?
> > 
> > This is what I can remember: we're introducing new view (say
> > _vsettings), which is specific for each sessions.
> In the current idea, this is not entirely true. The space
> is the same for all sessions. Simply, the tuples it creates
> contain the settings for the current session.
> 
> > This view should contain all settings which user allowed to
> > read and write. Inserts are prohibited to that view. Updates
> > are alowed only if user has enough privilages to the given
> > setting. E.g. user cannot changes a way FK are checked or
> > max nesting depth of a SELECT statement.
> Since the user will change the setting of current session,
> there won't be any interactions between users/sessions.
> > 
> > I guess, we should create this view lazily in order not to harm
> > performance. Please, make sure when you'll be working on the
> > patchset.
> In a sense, space will work lazily - it will create a tuple
> only when asked about it. The only thing we have to do when
> starting Tarantool (not a session!) Is to initialize an
> array of settings. Also, we must release it upon exiting
> Tarantool.
> 
> > 
> > Having such a view will alow us to:
> >   1. get rid of nasty pragma/set statements at all;
> >   2. will simplify connectors programming;
> >   3. improve security by allowing to *bind* values we
> >      wish to update, instead of concatenating big string
> >      like other broken DBMSes.
> > 
> > AFAIR, we decided to set {'string', 'any'} format for that
> > new view.
> Yes.
> 
> > 
> > Could you please summarize overall design and post it here
> > (or in discussions, whatever).
> > 
> > --
> > Regards, Kirill Yukhin