Re: [Tarantool-patches] [PATCH] box: remove unicode_ci for functions

[Kirill Yukhin <kyukhin@tarantool.org>]

Hello,

On 09 дек 14:24, Konstantin Osipov wrote:
> * Kirill Yukhin <kyukhin@tarantool.org> [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