[Tarantool-patches] [PATCH 0/4] session settings fixes

[Chris Sosnin]

Hi!

> On 3 Apr 2020, at 20:09, Peter Gulutzan <pgulutzan at ocelot.ca> wrote:
> 
> Hi,
> 
> Re:
> SETTING SET "sql_default_engine" = 'memtx';
> 
> Adding a new reserved word SETTING, without advance notice,
> should be against policy. It causes a slight risk
> of breaking an existing application.
> 
> I had hoped for
> UPDATE _SETTINGS_DEFAULT_ENGINE SET VALUE = 'memtx';

Implementing this syntax would either require creating a table for each setting
or adding new keywords, since this is the same as updating tables.

Moreover, SET VALUE construction also is not supported, so we still need
to reserve a new word.

We can borrow another MySQL syntax — SET SESSION name = value
What do you think about this option?

> I claim that is just as "user friendly" -- it
> adds two words, but it removes quotation marks.
> And it does not require that users learn new syntax
> because UPDATE ... SET is well known.
> 
> Notice that I can already do this -- almost.
> This is legal:
> CREATE VIEW _SETTINGS_DEFAULT_ENGINE AS
>     SELECT "value" AS value
>     FROM "_session_settings"
>     WHERE "name" = 'sql_default_engine';
> The flaw is that views are not updatable.
> But I don't regard that as a big problem
> because this is not a proposal to make
> all views updatable. It only requires:
> when you see that exact UPDATE statement,
> transform it to box.session._settings:update.
> And similarly for sql_defer_foreign_keys etc.
> 
> Alternatively, users could create a Lua function
> X which updates
> _session_settings, vaguely like this
> box.schema.func.create('X',
>     {language = 'LUA',
>      returns = 'string',
>      body = [[function ()
> box.space._session_settings:update('sql_default_engine', {{'=', 2, 'memtx'}});
>               return 'memtx changed'
>               end]],
>      is_sandboxed = false,
>      exports = {'LUA', 'SQL'},
>      is_deterministic = true})
> then allow this SQL syntax:
> CALL X();
> Again, I claim that this is just as "user friendly"
> because -- as far as I can tell -- some people think
> saving keystrokes is the same as being friendly.
> Nikita Pettik explained that issue#4711 is for a shortcut
> and that is short.
> Eventually we will probably want to support CALL anyway,
> and it is already a reserved word.
> 
> Thus there are "user-friendly" alternatives that do not
> require new proprietary syntax.
> 
> Peter Gulutzan
>