On 1 Nov 2018, at 19:31, Никита Петтик <kitnerh@gmail.com> wrote:

On 1 Nov 2018, at 18:39, Konstantin Osipov <kostja@tarantool.org> wrote:

* n.pettik <korablev@tarantool.org> [18/11/01 16:11]:

I guess, because

1) It is not real collation and is not presented in
_collation. So for a user it would be strange to see
a gap between 2 and 4 in _collation, which can not be
set.

Let's insert it there.

So, you insist on id == 3, right? Again, if user process select
rom _collation space, one won’t see entry with id == 3.
On the other hand, if user attempts at inserting id == 3,
one will get an error.

No, I don't insist yet. Why not insert a special row in there?

Because insertion to _collation would result in creation
of collation objects. Meanwhile, in fact we need only ID
to distinguish BINARY and no-collation. The rest is the
same for them. So, it makes sense to store only ID within
space format. That is my point.

is consistent to has its ID near COLL_NONE, in a "special
range" of collation identifiers.

Uhm, AFAIU we have two binary collations. One is "collation is not
set" and another is "collation binary". Which one did you mean
now?

FIrst one is not collation at all. It is rather “absence” of any collation.
The second one is sort of “surrogate” and in terms of functionality
means the same. However, its id will be stored in space format in
order to indicate that BINARY collation should be forced during
comparisons.

I think we could use internal ids to reference both cases. For
these both ids we could have surrogate rows in _coll system space,
they won't harm. This will make things easier in the future. 

Ok,  how do you suggest to call “absence” of collation? Like this:

box.space._collation:select()

---
- - [1, 'unicode', 1, 'ICU', '', {}]
 - [2, 'unicode_ci', 1, 'ICU', '', {'strength': 'primary’}]
 - [3, ‘none', 1, 'ICU', '', {}]
...

It is nonsense, IMHO. No collation is like “no collation at all” -
nothing represents it, especially visible for user. With BINARY
collation it would look even more suspicious:

- - [1, 'unicode', 1, 'ICU', '', {}]
 - [2, 'unicode_ci', 1, 'ICU', '', {'strength': 'primary’}]
 - [3, ‘none', 1, 'ICU', '', {}]
 - [4, ‘binary', 1, 'ICU', '', {}]

It would confuse users who don’t use SQL: in Tarantool NoSQL
there is no difference between “binary” and “no-collation”.
Moreover, to keep things consistent, we would have to  make
default collation be ’none’ instead of absence of collation.
It means that field def without explicitly set collation would
have ’none’ collation in format. For instance:

*before*

- [{'affinity': 66, 'type': ’string', 'nullable_action': 'abort', 'name': 'ID', 'is_nullable': false}]

*after*

- [{'collation': 3, 'affinity': 66, 'type': 'string', 'nullable_action': 'abort',
   'name': 'ID', 'is_nullable': false}]

This is going to be the same mess as with NO ACTION and DEFAULT,
which are mostly the same, but not quite, so we'd better prepare.

It is considered to be mess due to SQLite legacy. On the other hand, all
these manipulations with collations follow SQL ANSI.

All points considered, I would prefer to introduce only another one ID
(alongside with COLL_NONE ID) and prohibit to create collations with
these ids. OR, add surrogate “binary collation” to _collation with id == 3,
but not both “binary” and “none”.