From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pgulutzan@ocelot.ca>
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 379C44696C3
 for <tarantool-patches@dev.tarantool.org>;
 Wed,  8 Apr 2020 18:03:46 +0300 (MSK)
References: <8dc7be67-fc78-dd42-0634-83692259f0a5@ocelot.ca>
 <1433D33E-327F-4365-BB52-8BB9C6B539D5@tarantool.org>
 <0ab201d60d89$c39dd5f0$4ad981d0$@tarantool.org>
From: Peter Gulutzan <pgulutzan@ocelot.ca>
Message-ID: <fceeb274-0c7f-851d-db49-6ebb542cfd49@ocelot.ca>
Date: Wed, 8 Apr 2020 09:03:43 -0600
MIME-Version: 1.0
In-Reply-To: <0ab201d60d89$c39dd5f0$4ad981d0$@tarantool.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [Tarantool-patches] [PATCH 0/4] session settings fixes
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: Timur Safin <tsafin@tarantool.org>, 'Chris Sosnin' <k.sosnin@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org


On 2020-04-08 3:40 a.m., Timur Safin wrote:
<cut>
 > Peter, after multiple rounds of discussions here (one incompatible 
way against another incompatible way) we tend to prefer the simpler syntax
 >
 >     SET SESSION sqlconfigname = value
 >
 > because it's quite simpler, looks similar to MySQL way (though still 
is not part of standard), and would require less intrusive patch to 
parser. Introducing all configuration settins as separate system spaces 
(via hardcoding in the engine) looked to us slightly more intrusive 
(while still being not as much closer to the standard way).
 >
 > Minuses against minuses on both sides.
 >
 > What do you think, Peter?

My main objection to SETTING SET was that it
might cause an existing legal statement to become illegal.
I have asked C. Sosnin whether SET SESSION solves that.

My other objection was about proprietary syntax.
SET SESSION is not extremely different from standard SQL
SET SESSION CHARACTERISTICS (which I realize is too long),
and proprietary syntax is less bad if another vendor
does it. Incidentally MySQL handles this correctly:
CREATE PROCEDURE p()
BEGIN
   DECLARE session INTEGER;
   SET session = 5;
END;
Eventually, when Tarantool supports declared variables,
I hope everyone will remember that should be legal.

Thank you for considering alternative suggestions.
Please proceed with what you all regard as least intrusive.

Peter Gulutzan