From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rhino.ch-server.com (rhino.ch-server.com [209.59.190.103]) (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 76DF74696C3 for ; Fri, 3 Apr 2020 20:09:25 +0300 (MSK) From: Peter Gulutzan Message-ID: <8dc7be67-fc78-dd42-0634-83692259f0a5@ocelot.ca> Date: Fri, 3 Apr 2020 11:09:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: [Tarantool-patches] [PATCH 0/4] session settings fixes List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-patches@dev.tarantool.org 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'; 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