From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 09CBE22A76 for ; Thu, 25 Jul 2019 08:04:49 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BODfZJUSUBX8 for ; Thu, 25 Jul 2019 08:04:48 -0400 (EDT) Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id B955422A6B for ; Thu, 25 Jul 2019 08:04:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: [tarantool-patches] Re: [PATCH 2/2] sql: transactional DDL From: "n.pettik" In-Reply-To: <981da4b5-8c1e-9acb-5983-3ccfe9cee25f@tarantool.org> Date: Thu, 25 Jul 2019 15:04:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7ABE8B93-9600-4B79-A3D0-EBDB8F00DCBB@tarantool.org> References: <5863bb4286a3e45b3521420273d89347bd331a92.1563576462.git.v.shpilevoy@tarantool.org> <981da4b5-8c1e-9acb-5983-3ccfe9cee25f@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org Cc: Vladislav Shpilevoy > On 24 Jul 2019, at 23:58, Vladislav Shpilevoy = wrote: > On 24/07/2019 15:23, n.pettik wrote: >>=20 >> Thanks, the only dubious nit I can spot: should we >> set initiateTTrans for DDL operations which consist >> of one box operations? >=20 > Yeah, I thought about it, and even made it and reverted back > several times having some doubts 'code consistency vs > transaction necessity'. >=20 > After all I decided, that each DDL op should be transactional, > even if consists of one statement. Because 1) it is consistent > with other SQL DDL, 2) it protects us from the case when SQL > DDL will complicate. I think, the latter matters the most, taking > into account incoming information schema, when even a simple > index creation will insert into _index, into something like > _constraint_name to ensure name uniqueness, etc. Ok, I was driven by the same thoughts. Thanks, now LGTM.