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 4643F2BDA7 for ; Sun, 5 May 2019 08:16:36 -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 UW2WB5COwXID for ; Sun, 5 May 2019 08:16:36 -0400 (EDT) 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 turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id C021D2BD18 for ; Sun, 5 May 2019 08:16:35 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v1 3/3] sql: make SQL_TARANTOOL_ERROR the only errcode of OP_Halt References: <2b1c4f5e030ffa41069a3839f6ba39826ea739e1.1555072183.git.imeevma@gmail.com> <20190426073705.GB23413@tarantool.org> <0CEB3ED4-A19F-49FE-A074-5BD174D7FCF4@tarantool.org> From: Imeev Mergen Message-ID: <91100cee-d622-9e53-bb09-60c4d62f762e@tarantool.org> Date: Sun, 5 May 2019 15:16:32 +0300 MIME-Version: 1.0 In-Reply-To: <0CEB3ED4-A19F-49FE-A074-5BD174D7FCF4@tarantool.org> Content-Type: multipart/alternative; boundary="------------D756380B606D745B3299F4D5" Content-Language: en-US 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: "n.pettik" , tarantool-patches@freelists.org This is a multi-part message in MIME format. --------------D756380B606D745B3299F4D5 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit On 4/29/19 2:35 AM, n.pettik wrote: > > >> On 26 Apr 2019, at 10:37, Mergen Imeev > > wrote: >> >> On Mon, Apr 15, 2019 at 06:19:34PM +0300, n.pettik wrote: >>> 'make ... the only errcode of OP_Halt’ -> >>> make … be the only ... >>> >>>> On 12 Apr 2019, at 15:34,imeevma@tarantool.org >>>> wrote: >>>> >>>> After this patch, the only error code that the OP_Halt opcode >>>> will work with is SQL_TARANTOOL_ERROR. >>> >>> So, why do we need it at all now? Let’s use simple flag >>> is_aborted like in parser. >>> >> I could not do it now. >> I think we will do this when rc is one of >> SQL_OK, SQL_ROW, SQL_DONE or SQL_TARANTOOL_ERROR. This will be in >> the next patch-set. > > That’s OK, but still don’t understand what prevents you from > doing it right now..BTW, I don’t see corresponding patch in the > patch-set you’ve already sent (next one). The rc field is used to return some information from functions that return an error code in case something went wrong. In this regard, I think that we can completely remove this field instead of replacing it with is_aborted. However, after I tried to do this, I found that at the moment it had too many connections with the code. I'm not quite sure that it will be safe to remove the rc field right now. I would suggest removing some unused modules and reworking the memory system into SQL before we remove the rc field from the Vdbe structure. --------------D756380B606D745B3299F4D5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit


On 4/29/19 2:35 AM, n.pettik wrote:


On 26 Apr 2019, at 10:37, Mergen Imeev <imeevma@tarantool.org> wrote:

On Mon, Apr 15, 2019 at 06:19:34PM +0300, n.pettik wrote:
'make ... the only errcode of OP_Halt’ ->
make … be the only ...

On 12 Apr 2019, at 15:34, imeevma@tarantool.org wrote:

After this patch, the only error code that the OP_Halt opcode
will work with is SQL_TARANTOOL_ERROR.

So, why do we need it at all now? Let’s use simple flag
is_aborted like in parser.

I could not do it now.
I think we will do this when rc is one of
SQL_OK, SQL_ROW, SQL_DONE or SQL_TARANTOOL_ERROR. This will be in
the next patch-set.

That’s OK, but still don’t understand what prevents you from
doing it right now..BTW, I don’t see corresponding patch in the
patch-set you’ve already sent (next one).
The rc field is used to return some information from functions
that return an error code in case something went wrong. In this
regard, I think that we can completely remove this field instead
of replacing it with is_aborted. However, after I tried to do
this, I found that at the moment it had too many connections with
the code. I'm not quite sure that it will be safe to remove the rc
field right now. I would suggest removing some unused modules and
reworking the memory system into SQL before we remove the rc field
from the Vdbe structure.
--------------D756380B606D745B3299F4D5--