From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 9632C46971A for ; Mon, 9 Dec 2019 14:24:30 +0300 (MSK) Received: by mail-lj1-f174.google.com with SMTP id j6so15204112lja.2 for ; Mon, 09 Dec 2019 03:24:30 -0800 (PST) Date: Mon, 9 Dec 2019 14:24:28 +0300 From: Konstantin Osipov Message-ID: <20191209112428.GB25729@atlas> References: <20191129233922.36600-1-k.sosnin@tarantool.org> <20191130203439.GA23478@atlas> <13437800-f8ec-1964-f7d7-a01581e242ad@tarantool.org> <20191202070715.GA27802@atlas> <20191206114244.umbeo556b2atuhjm@tarantool.org> <20191206201718.GA7299@atlas> <20191209110631.srknhyc3zpn5cjsy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191209110631.srknhyc3zpn5cjsy@tarantool.org> 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: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy * Kirill Yukhin [19/12/09 14:11]: > > > > > >> 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. > > > > > > It was clearly pointed that proposal in #4467 is broken by > > > design. Please see [1] for details. Having that said I think > > > we should consider the proposal rejected and won't try to invent > > > any new workarounds. > > > > > > [1] - https://github.com/tarantool/tarantool/issues/4467#issuecomment-527210486 and later. > > > > Even if you think the proposal is broken the problem is there > > and needs resolution, not aggravation. > > > > Re initial proposal being broken I admitted it in the comment. > > We'll have to do an incompatible change and violate ANSI - in > > order to make the product usable. I suggested to add a > > case-insensitive unique index to every system space already. > > So, the proposal is to break backward compatibility and ANSI to > make visual basic programmers happy? No, we won't do that in > observable future. Who is "we"? I don't see this has been discussed & rejected, so why are you thinking you can make this decision? Maybe "we" instead of making "decisions" goes to users and customers and asks them what they expect? > > As to the suggestion being broken - it will allow one to get rid > > of uppercase-before-store and be mostly ansi compatible. > > I do not see any issue here. Yes, this is kind of obvious. -- Konstantin Osipov, Moscow, Russia