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 162692936A for ; Thu, 1 Nov 2018 16:06:13 -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 vUQ8ZzN61LMq for ; Thu, 1 Nov 2018 16:06:13 -0400 (EDT) Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (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 BCC3C2135A for ; Thu, 1 Nov 2018 16:06:12 -0400 (EDT) Date: Thu, 1 Nov 2018 23:06:10 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation Message-ID: <20181101200610.GB5887@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> <20181101153915.GL30032@chai> <95CB17D5-E3ED-4B05-A289-983E2FD0DE37@gmail.com> <20181101200027.GA5887@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181101200027.GA5887@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: =?utf-8?B?0J3QuNC60LjRgtCwINCf0LXRgtGC0LjQug==?= Cc: tarantool-patches@freelists.org, Vladislav Shpilevoy My point is - in future you may want an object with some kind of context to represent binary and absent collation. Right now an id is sufficient in all contexts, but in future it may be easier to treat all collations the same way. For example, collation "weight" in comparisons could be represent as an integer number. As long as you don't have an object for binary and "none" collations, you will have to treat them in a special way, while you could simply compare their strength with each other. The same is about collation name - you may need to print collation name in an error message. If "none" and "binary" are only ids, you will, once again, have to treat them separately. * Konstantin Osipov [18/11/01 23:00]: -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov