From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tarantool-patches-bounce@freelists.org>
Received: from localhost (localhost [127.0.0.1])
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 46B54255EE
	for <tarantool-patches@freelists.org>; Wed, 24 Jul 2019 19:30:16 -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 Zkwg46WiO5v0 for <tarantool-patches@freelists.org>;
	Wed, 24 Jul 2019 19:30:16 -0400 (EDT)
Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103])
	(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 F34B7255ED
	for <tarantool-patches@freelists.org>; Wed, 24 Jul 2019 19:30:15 -0400 (EDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: [tarantool-patches] Re: [PATCH v2 2/2] sql: fix error in case
 ARRAY/MAP converted to SCALAR
From: "n.pettik" <korablev@tarantool.org>
In-Reply-To: <20190724223706.GD13150@atlas>
Date: Thu, 25 Jul 2019 02:30:12 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <87724483-B69D-4913-A17F-0754D9C53653@tarantool.org>
References: <cover.1563955619.git.imeevma@gmail.com>
 <67e721f4818f51861383cdf71cc88c63e45ab450.1563955619.git.imeevma@gmail.com>
 <BEF40429-567A-42EB-92F1-01C8DB036886@tarantool.org>
 <20190724223706.GD13150@atlas>
Sender: tarantool-patches-bounce@freelists.org
Errors-to: tarantool-patches-bounce@freelists.org
Reply-To: tarantool-patches@freelists.org
List-Help: <mailto:ecartis@freelists.org?Subject=help>
List-Unsubscribe: <mailto:tarantool-patches-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: tarantool-patches <tarantool-patches.freelists.org>
List-Subscribe: <mailto:tarantool-patches-request@freelists.org?Subject=subscribe>
List-Owner: <mailto:>
List-post: <mailto:tarantool-patches@freelists.org>
List-Archive: <http://www.freelists.org/archives/tarantool-patches>
To: tarantool-patches@freelists.org
Cc: Imeev Mergen <imeevma@tarantool.org>, Konstantin Osipov <kostja@tarantool.org>



> On 25 Jul 2019, at 01:37, Konstantin Osipov <kostja@tarantool.org> =
wrote:
>=20
> * n.pettik <korablev@tarantool.org> [19/07/24 17:03]:
>>> 		assert(memIsValid(pIn1));
>>> 		if (mem_apply_type(pIn1, type) !=3D 0) {
>>> -			diag_set(ClientError, ER_SQL_TYPE_MISMATCH,
>>> -				 sql_value_text(pIn1),
>>> +			const char *value;
>>> +			if ((pIn1->flags & MEM_Subtype) !=3D 0 &&
>>> +			    pIn1->subtype =3D=3D SQL_SUBTYPE_MSGPACK) {
>>> +				if (mp_typeof(*pIn1->z) =3D=3D MP_MAP)
>>> +					value =3D "map";
>>> +				else
>>> +					value =3D "array";
>>> +			} else {
>>> +				value =3D (const char =
*)sql_value_text(pIn1);
>>=20
>>=20
>> Why not simply patch sql_value_text() to make it convert
>> map/array to string representation? I=E2=80=99m afraid this is
>> unlikely to be the only place where such error may occur.
>=20
> Perhaps I am missing the context, but because we don't want to=20
> implicitly convert these values to text in SQL?

It=E2=80=99s not about implicit conversion, it=E2=80=99s only about text =
representation
(like mp_fprint()).

> Soon we will be able to work with these values in SQL queries,

It=E2=80=99s extremely doubtful statement.

> so we simply need
> to make sure we can pass them around expression trees for now?

Actually, we can=E2=80=99t now.

>=20
> --=20
> Konstantin Osipov, Moscow, Russia
>=20