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 46A942C48A for ; Thu, 1 Nov 2018 11:39:19 -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 lRFjNP0nasst for ; Thu, 1 Nov 2018 11:39:19 -0400 (EDT) Received: from smtp10.mail.ru (smtp10.mail.ru [94.100.181.92]) (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 04EC82C0E3 for ; Thu, 1 Nov 2018 11:39:18 -0400 (EDT) Date: Thu, 1 Nov 2018 18:39:15 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation Message-ID: <20181101153915.GL30032@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> <2B8A8EDD-2479-4C1F-9FF3-E17B16DFB0AE@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2B8A8EDD-2479-4C1F-9FF3-E17B16DFB0AE@tarantool.org> 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: Vladislav Shpilevoy * n.pettik [18/11/01 16:11]: > >> 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 == 3, right? Again, if user process select > rom _collation space, one won’t see entry with id == 3. > On the other hand, if user attempts at inserting id == 3, > one will get an error. No, I don't insist yet. Why not insert a special row in there? > >> 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 “absence” of any collation. > The second one is sort of “surrogate” 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. I think we could use internal ids to reference both cases. For these both ids we could have surrogate rows in _coll system space, they won't harm. This will make things easier in the future. This is going to be the same mess as with NO ACTION and DEFAULT, which are mostly the same, but not quite, so we'd better prepare. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov