Tarantool development patches archive
 help / color / mirror / Atom feed
From: Imeev Mergen <imeevma@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
	tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH v1 4/9] sql: rework diag_set() in OP_Halt
Date: Mon, 3 Jun 2019 11:41:42 +0300	[thread overview]
Message-ID: <2f731c49-b8c4-f25b-a0c8-b5dcf382b60c@tarantool.org> (raw)
In-Reply-To: <0208a503-1a04-fb78-cf8b-563185c5ab42@tarantool.org>

Hi! Thank you for the review! My answers below. Also, I think I'm
going to drop this patch, since I plan to move the error code from
p5 to p2 in the next patch.

On 6/2/19 7:35 PM, Vladislav Shpilevoy wrote:
>
> On 28/05/2019 14:39, imeevma@tarantool.org wrote:
>> Prior to this patch, the way to set Tarantool error in OP_Halt was
>> too universal. It was possible to set a description of the error
>> that does not match its errcode.
> There was a concrete reason, why it was possible - because different
> error codes have different arguments of various types, and the only way
> to set an error at parsing stage is to allow to set arbitrary error
> message to any error code. Without '...', va_arg etc. Besides, we could
> use it to set correct line number and function name in future. Now you
> use diag_set, which restricts us.
>
> So why do you need that patch? We will need to revert it when an error
> appears requiring more than one argument, or an argument of not
> const char * type. That will definitely happen.
For some reason, manually creating an error message looks a bit
wrong to me. How about creating a new macro to create such
messages, for example, diag_prepare(), which takes the same
arguments as diag_set() and returns the complete error message?

>> This change will also make it
>> easier to work with an error in OP_Halt, since you no longer need
>> to create a complete error message.>
>> Example of wrong error code:
>> ...
>>
>> tarantool> box.execute('select 1 limit true')
>> ---
>> - error: Only positive integers are allowed in the LIMIT clause
>> ...
>>
>> tarantool> box.error.last().code
>> ---
>> - 0
>> ...
>> ---
> This is not because of box_error_set usage.
>
> tarantool> box.error({code = 123, reason = 'test'})
> ---
> - error: test
> ...
>
> tarantool> box.error.last().code
> ---
> - 123
> ...
>
> This example uses box_error_set() too, but the error
> code is kept. The bug in SQL could be fixed in a few lines,
> and you did it. But somewhy decided to break generic
> error creation alongside.
>
> The whole patch could be shrunk to this (+ tests):
>
>> diff --git a/src/box/sql/select.c b/src/box/sql/select.c
>> index d3472a9..3f0b540 100644
>> --- a/src/box/sql/select.c
>> +++ b/src/box/sql/select.c
>> @@ -2116,6 +2116,7 @@ computeLimitRegisters(Parse * pParse, Select * p, int iBreak)
>>   				  0, 0,
>>   				  wrong_limit_error,
>>   				  P4_STATIC);
>> +		sqlVdbeChangeP5(v, ER_SQL_EXECUTE);>
>>   		sqlVdbeResolveLabel(v, positive_limit_label);
>>   		VdbeCoverage(v);
>> @@ -2178,6 +2178,7 @@ computeLimitRegisters(Parse * pParse, Select * p, int iBreak)
>>   					  0, 0,
>>   					  wrong_offset_error,
>>   					  P4_STATIC);
>> +			sqlVdbeChangeP5(v, ER_SQL_EXECUTE);
>>   
>>   			sqlVdbeResolveLabel(v, positive_offset_label);
>>               		sqlReleaseTempReg(pParse, r1);
True, but I think I won't need this after I move errcode from p5
to p2 in the next patch.

  reply	other threads:[~2019-06-03  8:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 11:39 [tarantool-patches] [PATCH v1 0/9] sql: set errors in VDBE using diag_set() imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 1/9] sql: remove mayAbort field from struct Parse imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 2/9] sql: remove error codes SQL_TARANTOOL_*_FAIL imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 3/9] sql: remove error ER_SQL imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 4/9] sql: rework diag_set() in OP_Halt imeevma
2019-06-02 16:35   ` [tarantool-patches] " Vladislav Shpilevoy
2019-06-03  8:41     ` Imeev Mergen [this message]
2019-06-04 19:34       ` Vladislav Shpilevoy
2019-06-08 12:11         ` Mergen Imeev
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 5/9] sql: make SQL_TARANTOOL_ERROR the only errcode of OP_Halt imeevma
2019-06-02 16:35   ` [tarantool-patches] " Vladislav Shpilevoy
2019-06-03 11:53     ` Mergen Imeev
2019-06-04 19:34       ` Vladislav Shpilevoy
2019-06-08 12:15         ` Mergen Imeev
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 6/9] sql: remove error SQL_INTERRUPT imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 7/9] sql: remove error SQL_MISMATCH imeevma
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 8/9] sql: use diag_set() to set an error in SQL functions imeevma
2019-06-02 16:35   ` [tarantool-patches] " Vladislav Shpilevoy
2019-06-03 11:54     ` Mergen Imeev
2019-05-28 11:39 ` [tarantool-patches] [PATCH v1 9/9] sql: set errors in VDBE using diag_set() imeevma
2019-06-02 16:34   ` [tarantool-patches] " Vladislav Shpilevoy
2019-06-03 12:10     ` Mergen Imeev
2019-06-03 12:20       ` Mergen Imeev
2019-06-09 17:14 ` [tarantool-patches] Re: [PATCH v1 0/9] " Vladislav Shpilevoy
2019-06-13  9:44 ` Kirill Yukhin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f731c49-b8c4-f25b-a0c8-b5dcf382b60c@tarantool.org \
    --to=imeevma@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='[tarantool-patches] Re: [PATCH v1 4/9] sql: rework diag_set() in OP_Halt' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox