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 8313C25D97
	for <tarantool-patches@freelists.org>; Thu,  1 Aug 2019 06:27:12 -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 1ap2C-vsVhT9 for <tarantool-patches@freelists.org>;
	Thu,  1 Aug 2019 06:27:12 -0400 (EDT)
Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113])
	(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 DB0D825D85
	for <tarantool-patches@freelists.org>; Thu,  1 Aug 2019 06:27:11 -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 2/2] sql: make LIKE predicate
 dependent on collation
From: "n.pettik" <korablev@tarantool.org>
In-Reply-To: <9DFC7444-7C8D-4DB0-B059-948122587CE4@tarantool.org>
Date: Thu, 1 Aug 2019 13:27:07 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1731E5BF-8ADB-4D22-AF6F-52211E7BA33D@tarantool.org>
References: <cover.1563057282.git.roman.habibov@tarantool.org>
 <67ec7b5425d16078e45571c99ba9b58859b3c7b8.1563057282.git.roman.habibov@tarantool.org>
 <C4250A78-E57F-4DCF-B67B-364DED1E9562@tarantool.org>
 <9DFC7444-7C8D-4DB0-B059-948122587CE4@tarantool.org>
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: Roman Khabibov <roman.habibov@tarantool.org>, Kirill Yukhin <kyukhin@tarantool.org>


>>> * @param pisComplete True if the only wildcard is '%' in the
>>> *                    last character.
>>> * @retval True if the given expr is a LIKE operator & is
>>> @@ -276,9 +274,20 @@ like_optimization_is_valid(Parse *pParse, Expr =
*pExpr, Expr **ppPrefix,
>>> 		 */
>>> 		return 0;
>>> 	}
>>> +
>>> +	/* Only for "binary" and "unicode_ci" collations. */
>>=20
>> Why only two collations? Why not =E2=80=9Cunicode=E2=80=9D for =
instance?
>> What if collation is a part of expression, not field:
>> =E2=80=A6 a COLLATE =E2=80=9Cunicode=E2=80=9D LIKE =E2=80=A6 ?
> For instance, we consider the following query '... WHERE x LIKE "A%" =
COLLATE "unicode"' (strength - tertiary). The optimization will be: "A" =
<=3D x < "B". Let's take x =3D=3D "aaa". Comparison of "aaa" and "A" =
gives us '1'. Comparison of  "aaa" and "B" gives us '-1'. In other =
words, "A" <=3D "aaa" < "B", but it is a bad result, because "aaa" is =
not LIKE "A%" COLLATE "unicode=E2=80=9D.

Ok, but occasionally test suite didn=E2=80=99t include test case
checking this situation. I=E2=80=99ve added it alongside with
clarifying comments and minor fixes and put on
the branch: np/sql-like-collation

https://github.com/tarantool/tarantool/tree/np/sql-like-collation

With these fixes LGTM.