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

[Mergen Imeev <imeevma@tarantool.org>]

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