From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 1539646970F for ; Wed, 27 Nov 2019 13:52:08 +0300 (MSK) Date: Wed, 27 Nov 2019 13:52:06 +0300 From: Mergen Imeev Message-ID: <20191127105206.GA16682@tarantool.org> References: <84ae817b52e0d9415a0b89c730792b1e0221ff24.1574510839.git.imeevma@gmail.com> <20191126211234.GF23422@atlas> <20191127051523.qm3mjvng4pnqoe4y@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v4 2/2] box: introduce _vsession_settings sysview List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org On Wed, Nov 27, 2019 at 01:34:32PM +0300, Konstantin Osipov wrote: > Pragmas are of course a dead end, but pragmas themselves are > unimportant, so it's still unclear why one should bother about them, > as opposed to, for example, caring about foreign key checks for all > front ends. > > But fine, assuming one wants to remove prgamas, adding extra overhead > to session management is a bad idea. One could have a global sysview > _vsettings with all the settings, perhaps even ones from box.cfg, and > that would be enough. Hi! Thanks for the review. However, I think you are a little wrong. We do not save these settings anywhere except for the struct session. When a user reads from the space, it creates tuples on the fly and passes them to the user. All of this can actually be read from the commit-message: box: introduce _vsession_settings sysview This patch creates the _vsession_settings sysview. This sysview contains names and values of the session settings. This sysview creates tuples on the fly using its own get() and create_iterator() methods. This allows us to get a tuple without having to save it anywhere. But this means that every time we get a tuple from this system view, it is a new tuple, even if they look the same: tarantool> v = box.space._vsession_settings tarantool> v:get({'sql_default_engine'}) ~= v:get({'sql_default_engine'}) --- - true ... Currently, only SQL settings can be extracted from this sysview, since the only session settings are SQL settings. Part of #4511 @TarantoolBot document Title: _vsession_settings system view _vsession_settings sysview is used to get the current session settings. List of currently available session settings: sql_default_engine sql_defer_foreign_keys sql_full_column_names sql_recursive_triggers sql_reverse_unordered_selects Debug build also have debug settings that could be obtained from this sysview: sql_parser_trace sql_select_trace sql_trace sql_vdbe_addoptrace sql_vdbe_debug sql_vdbe_eqp sql_vdbe_listing sql_vdbe_trace sql_where_trace Example of usage: tarantool> box.space._vsession_settings:get({'sql_default_engine'}) --- - ['sql_default_engine', 'memtx'] ... tarantool> box.space._vsession_settings:select() --- - - ['sql_default_engine', 'memtx'] - ['sql_defer_foreign_keys', false] - ['sql_full_column_names', false] - ['sql_recursive_triggers', true] - ['sql_reverse_unordered_selects', false] ... tarantool> box.space._vsession_settings:select('sql_g', {iterator='LE'}) --- - - ['sql_full_column_names', false] - ['sql_defer_foreign_keys', false] - ['sql_default_engine', 'memtx'] ...