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 56C642B996 for ; Thu, 1 Nov 2018 09:08:59 -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 C_c-VeI5NlmX for ; Thu, 1 Nov 2018 09:08:59 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 DD1E12B964 for ; Thu, 1 Nov 2018 09:08:58 -0400 (EDT) From: "n.pettik" Message-Id: <2B8A8EDD-2479-4C1F-9FF3-E17B16DFB0AE@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8D96BCB-F6FE-4F8E-8057-FA42A165F9A4" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: [tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation Date: Thu, 1 Nov 2018 16:08:56 +0300 In-Reply-To: <20181101125810.GA28156@chai> References: <80794eb0182261e1887adc60c170c550de91fabc.1540460716.git.korablev@tarantool.org> <2A51C9E8-2A24-4F04-ABF1-0983F4322E82@tarantool.org> <20181101113717.GB2340@chai> <84dc3919-fd62-143d-327b-6f7ae184be5e@tarantool.org> <20181101125810.GA28156@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 --Apple-Mail=_E8D96BCB-F6FE-4F8E-8057-FA42A165F9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1 Nov 2018, at 15:58, Konstantin Osipov = wrote: >=20 > * Vladislav Shpilevoy > [18/11/01 15:23]: >>=20 >> On 01/11/2018 14:37, Konstantin Osipov wrote: >>> * n.pettik [18/10/31 18:52]: >>>=20 >>> Sorry for a last-minute comment, but is there any reason why id >>> has to be 4294967294? Why not use the next spare id, it's 3 >>> AFAIR? >>=20 >>=20 >> I guess, because >>=20 >> 1) It is not real collation and is not presented in >> _collation. So for a user it would be strange to see >> a gap between 2 and 4 in _collation, which can not be >> set. >=20 > Let's insert it there. So, you insist on id =3D=3D 3, right? Again, if user process select rom _collation space, one won=E2=80=99t see entry with id =3D=3D 3. On the other hand, if user attempts at inserting id =3D=3D 3, one will get an error. >=20 >> 3) Actually binary collation =3D=3D no collation and it >> is consistent to has its ID near COLL_NONE, in a "special >> range" of collation identifiers. >=20 > Uhm, AFAIU we have two binary collations. One is "collation is not > set" and another is "collation binary". Which one did you mean > now? FIrst one is not collation at all. It is rather =E2=80=9Cabsence=E2=80=9D = of any collation. The second one is sort of =E2=80=9Csurrogate=E2=80=9D and in terms of = functionality means the same. However, its id will be stored in space format in order to indicate that BINARY collation should be forced during comparisons. --Apple-Mail=_E8D96BCB-F6FE-4F8E-8057-FA42A165F9A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1 Nov 2018, at 15:58, Konstantin Osipov <kostja@tarantool.org> wrote:

* Vladislav Shpilevoy = <v.shpilevoy@tarantool.org> [18/11/01 15:23]:

On 01/11/2018 14:37, = Konstantin Osipov wrote:
* n.pettik <korablev@tarantool.org> [18/10/31 18:52]:

Sorry for a last-minute comment, but is there = any reason why id
has to be  4294967294? Why not use = the next spare id, it's 3
AFAIR?


I guess, = because

1) It is not real collation and is = not presented in
_collation. So for a user it would be = strange to see
a gap between 2 and 4 in _collation, which = can not be
set.

Let's insert it there.

So, you = insist on id =3D=3D 3, right? Again, if user process = select
rom _collation space, one won=E2=80=99t see entry with = id =3D=3D 3.
On the other hand, if user attempts at inserting = id =3D=3D 3,
one will get an error.


3) = Actually binary collation =3D=3D no collation and it
is = consistent to has its ID near COLL_NONE, in a "special
range" of collation identifiers.
Uhm, AFAIU we have two binary = collations. One is "collation is not
set" and another is "collation binary". Which one did you = mean
now?

FIrst one = is not collation at all. It is rather =E2=80=9Cabsence=E2=80=9D of any = collation.
The second one is sort of =E2=80=9Csurrogate=E2=80=9D= and in terms of functionality
means the same. However, its id = will be stored in space format in
order to indicate that = BINARY collation should be forced = during
comparisons.

= --Apple-Mail=_E8D96BCB-F6FE-4F8E-8057-FA42A165F9A4--