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 5EF442321D for ; Tue, 9 Jul 2019 05:14:21 -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 KsVpf1qUStj0 for ; Tue, 9 Jul 2019 05:14:21 -0400 (EDT) Received: from smtp44.i.mail.ru (smtp44.i.mail.ru [94.100.177.104]) (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 ECF7520ACB for ; Tue, 9 Jul 2019 05:14:20 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH v1 1/1] sql: Fix UPDATE for types unknown to SQL. References: <132ca83597d0e9c2b4ef75bc8f0d03d22cdf27dd.1561736006.git.imeevma@gmail.com> <20190708101336.GA10686@tarantool.org> From: Imeev Mergen Message-ID: <09286d9d-870b-f5dd-f328-56d374173160@tarantool.org> Date: Tue, 9 Jul 2019 12:14:18 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3D0CD726C4ED48341A8B9C86" 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. --------------3D0CD726C4ED48341A8B9C86 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi! Thank you for review. My answer below. On 7/8/19 4:32 PM, n.pettik wrote: > >> Diff: >> >> diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c >> index f8cf1af..79232de 100644 >> --- a/src/box/sql/vdbe.c >> +++ b/src/box/sql/vdbe.c >> @@ -351,19 +351,22 @@ mem_apply_type(struct Mem *record, enum >> field_type type) >> return 0; >> case FIELD_TYPE_SCALAR: >> /* Can't cast MAP and ARRAY to scalar types. */ >> -if (record->subtype == SQL_SUBTYPE_MSGPACK) { >> +if ((record->flags & MEM_Blob) == MEM_Blob && > > Why do you need this additional check on MEM_Blob? > Is it possible that memory holds raw msgpack and its > type not blob? If so, please provide an example. > I'm not sure what you describe is possible. But it is impossible to say what type MEM has when you look at the SUBTYPE. At the same time, the subtype has any meaning only for BLOBs. Any other type has any SUBTYPE, and it is not checked anywhere. So, to avoid an error, when something, for example INT, throws an error when casting to SCALAR, I added these checks. --------------3D0CD726C4ED48341A8B9C86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Hi! Thank you for review. My answer below.

On 7/8/19 4:32 PM, n.pettik wrote:

Diff:

diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c
index f8cf1af..79232de 100644
--- a/src/box/sql/vdbe.c
+++ b/src/box/sql/vdbe.c
@@ -351,19 +351,22 @@ mem_apply_type(struct Mem *record, enum field_type type)
return 0;
case FIELD_TYPE_SCALAR:
/* Can't cast MAP and ARRAY to scalar types. */
- if (record->subtype == SQL_SUBTYPE_MSGPACK) {
+ if ((record->flags & MEM_Blob) == MEM_Blob &&

Why do you need this additional check on MEM_Blob?
Is it possible that memory holds raw msgpack and its
type not blob? If so, please provide an example.

I'm not sure what you describe is possible. But it is impossible
to say what type MEM has when you look at the SUBTYPE. At the same
time, the subtype has any meaning only for BLOBs. Any other type
has any SUBTYPE, and it is not checked anywhere. So, to avoid an
error, when something, for example INT, throws an error when
casting to SCALAR, I added these checks.

--------------3D0CD726C4ED48341A8B9C86--