From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtp16.mail.ru (smtp16.mail.ru [94.100.176.153])
 (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 E744646971A
 for <tarantool-patches@dev.tarantool.org>;
 Sun,  1 Dec 2019 17:36:04 +0300 (MSK)
References: <20191129233922.36600-1-k.sosnin@tarantool.org>
 <20191130203439.GA23478@atlas>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <13437800-f8ec-1964-f7d7-a01581e242ad@tarantool.org>
Date: Sun, 1 Dec 2019 15:36:02 +0100
MIME-Version: 1.0
In-Reply-To: <20191130203439.GA23478@atlas>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH] box: remove unicode_ci for functions
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Konstantin Osipov <kostja.osipov@gmail.com>, Chris Sosnin <k.sosnin@tarantool.org>, tarantool-patches@dev.tarantool.org

Hi, thanks for the review!

On 30/11/2019 21:34, Konstantin Osipov wrote:
> * Chris Sosnin <k.sosnin@tarantool.org> [19/11/30 07:03]:
>> 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.
> 
> 

Yeah, RFC is cool and all, but 'this is in an RFC' is not
a good justification, don't you think? Especially taking
into account, that this is our own RFC. It is not a
standard or something.

With Chris we did a little investigation, and here is what
we've found:

- The RFC does not explain why we need a case-insensitive
  index. This has nothing to do with conflicts. SQL always
  is and will be able to choose one name - the uppercased
  one;

- Despite the index is case insensitive, I still get an error
  when call a not uppercased function from SQL:

      box.cfg{}
      box.schema.func.create('func1', {language = 'Lua', is_deterministic = true,
                                       body = 'function(a) return a end',
                                       param_list = {'any'}, returns = 'string',
                                       exports = {'LUA', 'SQL'}})
      box.execute('SELECT func1(\'str\')')
      ---
      - null
      - Function 'FUNC1' does not exist
      ...

      box.execute('SELECT "func1"(\'str\')')
      ---
      - metadata:
        - name: '"func1"(''str'')'
          type: string
        rows:
        - ['str']
      ...

  As you can see, the index's case does not matter. It is
  insensitive, but I still need to write functions in a
  special register.

- Lua box.func.* is also case sensitive:

      tarantool> box.schema.func.create('func1')
      ---
      ...

      tarantool> box.schema.func.create('FUNC1')
      ---
      - error: Function 'FUNC1' already exists
      ...

      tarantool> box.func['FUNC1']
      ---
      - null
      ...

  The error message is really confusing. It says, that
  such a function already exists, but nonetheless I can't
  get it. This is ridiculous.

- As Peter said, _func behaves inconsistent with all the
  other system spaces.

- As Peter said, we did it just for SQL, but it affects
  non-SQL front ends. As you can see from the box.func.*
  example.

On the summary, this collation is clearly useless - its
case insensitivity does not help any of the listed problems.
Therefore, it is a bug.

I think the collation should be dropped.