From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <k.sosnin@tarantool.org>
Received: from smtp15.mail.ru (smtp15.mail.ru [94.100.176.133])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id F25D34696C3
 for <tarantool-patches@dev.tarantool.org>;
 Tue,  7 Apr 2020 19:32:22 +0300 (MSK)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Chris Sosnin <k.sosnin@tarantool.org>
In-Reply-To: <8dc7be67-fc78-dd42-0634-83692259f0a5@ocelot.ca>
Date: Tue, 7 Apr 2020 19:32:16 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1433D33E-327F-4365-BB52-8BB9C6B539D5@tarantool.org>
References: <8dc7be67-fc78-dd42-0634-83692259f0a5@ocelot.ca>
Subject: Re: [Tarantool-patches] [PATCH 0/4] session settings fixes
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Peter Gulutzan <pgulutzan@ocelot.ca>
Cc: tarantool-patches@dev.tarantool.org

Hi!

> On 3 Apr 2020, at 20:09, Peter Gulutzan <pgulutzan@ocelot.ca> wrote:
>=20
> Hi,
>=20
> Re:
> SETTING SET "sql_default_engine" =3D 'memtx';
>=20
> Adding a new reserved word SETTING, without advance notice,
> should be against policy. It causes a slight risk
> of breaking an existing application.
>=20
> I had hoped for
> UPDATE _SETTINGS_DEFAULT_ENGINE SET VALUE =3D '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 =E2=80=94 SET SESSION name =3D 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.
>=20
> 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" =3D '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.
>=20
> Alternatively, users could create a Lua function
> X which updates
> _session_settings, vaguely like this
> box.schema.func.create('X',
>     {language =3D 'LUA',
>      returns =3D 'string',
>      body =3D [[function ()
> box.space._session_settings:update('sql_default_engine', {{'=3D', 2, =
'memtx'}});
>               return 'memtx changed'
>               end]],
>      is_sandboxed =3D false,
>      exports =3D {'LUA', 'SQL'},
>      is_deterministic =3D 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.
>=20
> Thus there are "user-friendly" alternatives that do not
> require new proprietary syntax.
>=20
> Peter Gulutzan
>=20