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 3084624F12 for ; Wed, 24 Jul 2019 18:37:09 -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 Mpj5k6IaK3dy for ; Wed, 24 Jul 2019 18:37:09 -0400 (EDT) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (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 E508C2315F for ; Wed, 24 Jul 2019 18:37:08 -0400 (EDT) Date: Thu, 25 Jul 2019 01:37:06 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v2 2/2] sql: fix error in case ARRAY/MAP converted to SCALAR Message-ID: <20190724223706.GD13150@atlas> References: <67e721f4818f51861383cdf71cc88c63e45ab450.1563955619.git.imeevma@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Imeev Mergen * n.pettik [19/07/24 17:03]: > > assert(memIsValid(pIn1)); > > if (mem_apply_type(pIn1, type) != 0) { > > - diag_set(ClientError, ER_SQL_TYPE_MISMATCH, > > - sql_value_text(pIn1), > > + const char *value; > > + if ((pIn1->flags & MEM_Subtype) != 0 && > > + pIn1->subtype == SQL_SUBTYPE_MSGPACK) { > > + if (mp_typeof(*pIn1->z) == MP_MAP) > > + value = "map"; > > + else > > + value = "array"; > > + } else { > > + value = (const char *)sql_value_text(pIn1); > > > Why not simply patch sql_value_text() to make it convert > map/array to string representation? I’m afraid this is > unlikely to be the only place where such error may occur. Perhaps I am missing the context, but because we don't want to implicitly convert these values to text in SQL? Soon we will be able to work with these values in SQL queries, so we simply need to make sure we can pass them around expression trees for now? -- Konstantin Osipov, Moscow, Russia