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 8C4A628FD7 for ; Mon, 11 Mar 2019 08:12:53 -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 mwWn20HV9ydS for ; Mon, 11 Mar 2019 08:12:53 -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 40ED328FB7 for ; Mon, 11 Mar 2019 08:12:53 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: [tarantool-patches] Re: [PATCH 1/3] sql: remove SQL_LIKE_DOESNT_MATCH_BLOBS From: "n.pettik" In-Reply-To: <20190311080718.GF3101@chai> Date: Mon, 11 Mar 2019 15:12:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <819cad361d29e627f17cf38c6ca6ffd0e10d3e2b.1552149462.git.korablev@tarantool.org> <20190311080718.GF3101@chai> 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: Konstantin Osipov , Vladislav Shpilevoy > On 11 Mar 2019, at 11:07, Konstantin Osipov = wrote: >=20 > * Nikita Pettik [19/03/09 22:50]: >> We are going to always throw an error if value of BLOB type gets to = LIKE >> arguments, so code under is macro is not needed anymore. >=20 > What's the decision about LIKE for MP_STR + collaction binary or > no collation at all? Shouldn't we need this code as an optimized > implementation of LIKE for binary? Firstly, this optimisation has been turned off for quite a while. I=E2=80=99m not sure that it can be enabled without significant = patching. Secondly, MP_STR + binary (or none) collation is still stored as a string (MEM_Str in terms of VDBE), meanwhile deleted code was operating on real blob values (MEM_Blob): =E2=80=98'' - * The LIKE optimization trys to evaluate "x LIKE 'abc%'" as a range - * expression: "x>=3D'ABC' AND x<'abd'". But this requires that the = range - * scan loop run twice, once for strings and a second time for BLOBs. - * The OP_String opcodes on the second pass convert the upper and lower - * bound string constants to blobs. This routine makes the necessary = changes - * to the OP_String opcodes for that to happen. =E2=80=98=E2=80=99' Note that now LIKE doesn=E2=80=99t use implicitly set collation: tarantool> create table t1(id int primary key, a text collate "binary") --- ... tarantool> insert into t1 values (1, 'ABC') --- ... tarantool> select * from t1 where a like 'abc' --- - - [1, 'ABC'] =E2=80=A6 It is going to be fixed in = https://github.com/tarantool/tarantool/issues/3589 >=20 > --=20 > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 > http://tarantool.io - www.twitter.com/kostja_osipov