From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 18 Dec 2019 01:11:44 +0300 From: Alexander Turenko Message-ID: <20191217221143.parwzoyb3e327sw5@tkn_work_nb> References: <20191206113711.ctzr6x7sqbpr3xkd@tarantool.org> <20191206135009.GA6394@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191206135009.GA6394@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: v.shpilevoy@tarantool.org, Peter Gulutzan , tarantool-discussions@dev.tarantool.org, tarantool-patches@dev.tarantool.org Mergen, I don't have enough context here, but have questions about this proposal. Sorry if they were already discussed and I missed it. Most important question is that I don't understand why we don't want to provide language specific APIs for sessions settings. It looks both more convenient and more performant. See this and other questions and notes below. (CCed Peter, because he may have some opinion how SQL API should look.) WBR, Alexader Turenko. ---- AFAIR discussions around a space / view for session settings arose from Kostya O. proposal to move toward support of standard information schema views (please, correct me, if I remember it wrongly). Then it becomes out of scope somehow. But okay, let it being out. (BTW, I looked over SQL/Schemata 2011 and don't found anything like MySQL's GLOBAL_VARIABLES and SESSION_VARIABLES tables. It seems there is no standard table for session variables. I don't sure however.) ---- We have two basic variants: * Implement an API for session settings for each supported language (C, Lua, SQL) and a protocol for connectors. * Provide a system view / space (this is proposed by Mergen). First, a space / view is not most convenient way to operate on session settings from a language. Let's compare. Lua: | box.space._vsession_settings:get({'sql_default_engine'}).value | box.space._vsession_settings:update({'sql_default_engine'}, | {{'=', 'value', 'vinyl'}}) | | box.session.settings:get('sql_default_engine') | box.session.settings:set('sql_default_engine', 'vinyl') SQL: | SELECT "value" FROM "_vsession_settings" WHERE "name" = 'sql_default_engine' | UPDATE "_vsession_settings" SET "value" = 'vinyl' \ | WHERE "name" = 'sql_default_engine' | | SESSION GET 'sql_default_engine' | SESSION SET 'sql_default_engine' = 'vinyl' C (sketchy): | /* Read from a _vsession_settings. */ | | enum { | BOX_VSESSION_SETTINGS_VALUE_ID = 2 | }; | | char key[32]; | char *key_end = key; | key_end = mp_encode_array(key_end, 1); | key_end = mp_encode_str(key_end, "sql_default_engine", | sizeof("sql_default_engine") - 1); | | box_tuple_t *tuple; | box_iterator_t *it = box_index_iterator(BOX_VSESSION_SETTINGS_ID, 0, ITER_EQ, | key, key_end); | box_iterator_next(it, &tuple); | const char *buf = box_tuple_field(tuple, BOX_VSESSION_SETTINGS_VALUE_ID); | | uint32_t engine_len; | const char *engine = mp_decode_str(&buf, &engine_len); | | box_iterator_free(it); | | /* Update a value in _vsession_settings. */ | | | | /* Get and set with a language aware API. */ | | uint32_t engine_len; | const char *engine = box_session_get_str(SESSION_SQL_DEFAULT_ENGINE, | &engine_len); | | box_session_set_str(SESSION_SQL_DEFAULT_ENGINE, "vinyl", | sizeof("vinyl") - 1); Languare-aware APIs above are just examples. I propose to implement such APIs, but not how they should look exactly. To sum the examples up: it seems for me that language aware APIs are a way more simple for a user. Second, all tuples are msgpack encoded (at least now). So any get/set operation on _vspace_settings will require to encode and decode msgpack (yep, both encode and decode at once). It will be surely less performant then a hashmap lookup (session id -> struct session_settings) plus a field access. So, language aware API can be implemented in more performant way then general space-like one. It seems that we anyway need an API for connectors. So we can provide the proposed view, but don't use it internally to implement language specific APIs (for performance). ---- Re SET / SHOW, GET / SELECT -- I don't think it really matters so much. Maybe we should look for SQL/PSM and catch some syntax to make things look consistent in a future. Maybe we should add a keyword SESSION (as in my SQL API examples) to avoid possible future incompatibilities (say, with SQL/PSM). ---- Console session settings (like statements delimiter, input language, output format) are out of scope here?