From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 CBF2046971A for ; Mon, 9 Dec 2019 16:25:56 +0300 (MSK) Date: Mon, 9 Dec 2019 16:25:55 +0300 From: Kirill Yukhin Message-ID: <20191209132555.qn25wsxoa5lr4252@tarantool.org> 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> <20191209112428.GB25729@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191209112428.GB25729@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 Hello, On 09 дек 14:24, Konstantin Osipov wrote: > * 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"? We are team of Tarantool developers working for MailRU Group. We had pretty much discussions internally on the matter and came up with this decision: we won't break backward compatibility in order to add some sugar. > I don't see this has been discussed & rejected, so why are you > thinking you can make this decision? All I can see on the matter is issue #4467 which we agreed to be broken by design. I see no solid proposals neither in discussions nor in github issues on how it supposed to work. If it will occur - we'll happily consider it. > Maybe "we" instead of making "decisions" goes to users and > customers and asks them what they expect? Why not to ask if public demands free beer? Right now business dictates us to work on other things. -- Regards, Kirill Yukhin