[tarantool-patches] Re: [PATCH 2/3] Add surrogate ID for BINARY collation

[n.pettik]

> On 1 Nov 2018, at 15:58, Konstantin Osipov <kostja at tarantool.org> wrote:
> 
> * Vladislav Shpilevoy <v.shpilevoy at tarantool.org <mailto:v.shpilevoy at tarantool.org>> [18/11/01 15:23]:
>> 
>> On 01/11/2018 14:37, Konstantin Osipov wrote:
>>> * n.pettik <korablev at tarantool.org> [18/10/31 18:52]:
>>> 
>>> Sorry for a last-minute comment, but is there any reason why id
>>> has to be  4294967294? Why not use the next spare id, it's 3
>>> AFAIR?
>> 
>> 
>> 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.

> 
>> 3) Actually binary collation == no collation and it
>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20181101/eea46075/attachment.html>