From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 6049646970F for ; Wed, 27 Nov 2019 14:10:32 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id k8so13450625ljh.5 for ; Wed, 27 Nov 2019 03:10:32 -0800 (PST) Date: Wed, 27 Nov 2019 14:10:30 +0300 From: Konstantin Osipov Message-ID: <20191127111030.GB9233@atlas> References: <20191127105150.GA7232@atlas> <20191127110532.GA16764@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191127110532.GA16764@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 4/5] sql: replace control pragmas by SET List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Mergen Imeev [19/11/27 14:07]: > > Usually, if one allows SET statement, SET option_name (without > > "= new_value") prints the current setting. This does the job and > > makes the "_vsettings" system view unnecessary. > > > > Don't you think that having to use one piece of syntax to query a > > value and entirely different piece to assign it is, ehm, > > inconsistent, hard to learn & remember, and eventually hard to > > use? > > > You are right. This was also pointed by Vlad in previous > review: > "2. Ok, but now it looks really unusable when a user want's to > learn an option value. I will create a ticket, if this patchset > will be pushed and nobody will care about usability beforehand." But how are you going to fix it? By making SET statement powerful enough to query a value or by making the sysview updatable? Either way you fix it, the second patch will become unnecessary, don't you think? > Personally, I think this is easy to fix, and your > suggestion is good. In fact, I can fix this in this > patch-set if Vlad and Nikita agree with this solution. -- Konstantin Osipov, Moscow, Russia