From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kyukhin@tarantool.org>
Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106])
 (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 563D146970F
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 27 Nov 2019 08:15:25 +0300 (MSK)
Date: Wed, 27 Nov 2019 08:15:23 +0300
From: Kirill Yukhin <kyukhin@tarantool.org>
Message-ID: <20191127051523.qm3mjvng4pnqoe4y@tarantool.org>
References: <cover.1574510839.git.imeevma@gmail.com>
 <84ae817b52e0d9415a0b89c730792b1e0221ff24.1574510839.git.imeevma@gmail.com>
 <20191126211234.GF23422@atlas>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20191126211234.GF23422@atlas>
Subject: Re: [Tarantool-patches] [PATCH v4 2/2] box: introduce
 _vsession_settings sysview
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: Konstantin Osipov <kostja.osipov@gmail.com>, imeevma@tarantool.org, v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org

Hello,

On 27 ноя 00:12, Konstantin Osipov wrote:
> * imeevma@tarantool.org <imeevma@tarantool.org> [19/11/23 23:10]:
> > This patch creates the _vsession_settings sysview. This sysview
> > contains names and values of the session settings.
> 
> Having a session settings in a database that heavily multiplexes
> requests over the same connection is a bad idea: the features simply don't work
> together. A concurrent statement may tweak the setting while the
> previous statement is still in progress.

We consider pragmas a dead end and not going to extend them further.
However we still need a mechanism for storing session-related things,
like verbosity flags or default engine. We believe, that such settings
are related to the session, not to DB and that is why this patchset
was prepared.

Anyway, thanks a lot for your inputs.

--
Regards, Kirill Yukhin