From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 dev.tarantool.org (Postfix) with ESMTPS id 8591F46971A for ; Mon, 2 Dec 2019 17:36:34 +0300 (MSK) Date: Mon, 2 Dec 2019 17:36:33 +0300 From: Nikita Pettik Message-ID: <20191202143633.GA51923@tarantool.org> References: <20191129233922.36600-1-k.sosnin@tarantool.org> <20191130203439.GA23478@atlas> <13437800-f8ec-1964-f7d7-a01581e242ad@tarantool.org> <20191202070715.GA27802@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191202070715.GA27802@atlas> Subject: Re: [Tarantool-patches] [PATCH] box: remove unicode_ci for functions List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Vladislav Shpilevoy , Chris Sosnin , tarantool-patches@dev.tarantool.org On 02 Dec 10:07, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/12/01 19:29]: > > >> Unicode_ci collation breaks the general > > >> rule for objects naming, so we remove it > > >> in version 2.3.1 > > > > > > The code works according to RFC. > > > > > > There is a justification for this behaviour in RFC. > > Please see my reply with an explanation. The RFC was written > presuming https://github.com/tarantool/tarantool/issues/4467 > will be fixed. According to milestone (which is 'feature'), it is not going to be implemented soon. What is more, there's even no clearly stated proposal or RFC without contradictions. > The current way of uppercasing is broken - it is hard to use, > and people hit the problem almost immediately, especially newbies. > > Instead of fixing the "inconsistency", one should fix 4467 Just for the record, I have to say that I agree with Vlad and Chris. Function's name featuring unicode_ci collation at least seem to be strange. RFC says: ''' To avoid name clash, we will reserve these names by adding entries for them in _func system space. ''' That's all. I can't figure out what did author really mean by 'name clash'. We are able to create two different objects (of any kind: space, trigger etc) with the same in terms of case-insensetive collation (e.g. "t1" and "T1"). Why this rule should be violated for functions?