Fixes gh-2189 Field type UUID is now available in SQL

[pgulutzan]

In fact the intent is to fix gh-2189 and other issues that are duplicates or closely related because they're about sql + uuid:
gh-2151 gh-2176 gh-2177 gh-2190.
Also a few punctuation errors are fixed.
I added a label 2.9.1 -- this appears to be the relevant version but there are no release notes for it yet.
Some issues related to sql + uuid are being discussed in tarantool/tarantool#6164 comments but I don't expect them to affect documentation immediately.

[NickVolynkin]

@pgulutzan thank you! Please keep this PR open, we'll translate it right away and then merge both the doc updates and the translation.

[ImeevMA]

LGTM

[igormunkin]

@pgulutzan, thanks for the changes, LGTM, except the one question: I found no changes related to SCALAR comparison order mentioned in #2151. Is there a place, where this order is described?

[igormunkin]

Minor: why is this field added as a non-last attribute?

[pgulutzan]

It is not added as a non-last attribute. The text that I see in the changed file looks like this:
-- with all possible data types and aliases
CREATE TABLE t
(column1 BOOLEAN, column2 BOOL,
column3 INT PRIMARY KEY, column4 INTEGER,
column5 DOUBLE,
column6 NUMBER,
column7 STRING, column8 STRING COLLATE "unicode",
column9 TEXT, columna TEXT COLLATE "unicode_sv_s1",
columnb VARCHAR(0), columnc VARCHAR(100000) COLLATE "binary",
columnd UUID,
columne VARBINARY,
columnf SCALAR, columng SCALAR COLLATE "unicode_uk_s2");

[igormunkin]

Yes, I see. And the question is why did you change collumnd type to UUID, instead of making the new attribute collumng of UUID type? Anyway, I am totally OK with this change, just trying to get your point regarding it.

[pgulutzan]

So I misunderstood your question, sorry. For this example we can put the columns in any order. I was not trying to make a point. I am wondering now: is there any way that putting columns in a different order affects performance? But, regardless what the answer for that is, it won't matter for this example.

[igormunkin]

Minor: IMHO, "supported" fits much better here than "allowed" does. Feel free to ignore.

[pgulutzan]

I realize that if I say UUID(3) I get an error message that includes the word "supported".
However, the fact that I get an error message means that UUID(3) is not allowed.
If I had not gotten an error message, that would mean UUID(3) is allowed but meaningless
and probably will have no effect -- that would be my idea of "not supported". Understandable?

[pgulutzan]

@igormunkin: your question shows that I was careless when looking at #2151, I did not see that it was not marked as an SQL issue.
Re SQL ordering: I could add ", then UUIDs" at the end of this line:
https://www.tarantool.io/en/doc/latest/reference/reference_sql/sql_statements_and_clauses/#order-by-clause
"NULLs come first, then BOOLEANs, then numbers, then STRINGs, then VARBINARYs, then UUIDs."
but the significant changes are not in the SQL section of the manual, they are in the Lua section.
https://www.tarantool.io/en/doc/latest/book/box/data_model/
"When a scalar field contains values of different underlying types, the key order is: nils, then booleans, then numbers, then strings, then varbinaries."
and
https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/create_index/
"When there is a mix of types, the key order is: null, then booleans, then numbers, then strings, then byte arrays"
In both cases ", then uuids" should be added.
@NickVolynkin: should I treat the above changes as a separate issue and make a new pull request for #2151, or add a commit for this pull request?

[igormunkin]

@igormunkin: your question shows that I was careless when looking at #2151, I did not see that it was not marked as an SQL issue.

No problem. I was simply confused with the message, that #2151 will be also resolved in scope of this PR.

Re SQL ordering: I could add ", then UUIDs" at the end of this line:
https://www.tarantool.io/en/doc/latest/reference/reference_sql/sql_statements_and_clauses/#order-by-clause
"NULLs come first, then BOOLEANs, then numbers, then STRINGs, then VARBINARYs, then UUIDs."

Agree.

but the significant changes are not in the SQL section of the manual, they are in the Lua section.
https://www.tarantool.io/en/doc/latest/book/box/data_model/
"When a scalar field contains values of different underlying types, the key order is: nils, then booleans, then numbers, then strings, then varbinaries."
and
https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/create_index/
"When there is a mix of types, the key order is: null, then booleans, then numbers, then strings, then byte arrays"
In both cases ", then uuids" should be added.

Agree.

@NickVolynkin: should I treat the above changes as a separate issue and make a new pull request for #2151, or add a commit for this pull request?

IMHO, it would be better to resolve #2151 in a separate PR, since it relates to SCALAR and UUID for both language runtimes. I also summon @ImeevMA here as an author of the ticket and the patch.

[pgulutzan]

@igormunkin, I think that you are right. If @NickVolynkin agrees, let us say:
All reviews of this pull request have passed except the one from @tsafin,
and it fixes all the issues that I mentioned except issue#2151,
so we can end it soon.
Issue#2151 will not be fixed in the scope of this PR, I will make a separate pull request.
Incidentally I looked more closely and saw two more things in
https://www.tarantool.io/en/doc/latest/book/box/data_model/
"
scalar. Values in a scalar field can be boolean or integer or unsigned or double or number or decimal or string or varbinary – but not array or map or tuple. Examples: true, 1, 'xxx'.
"
..."
any. Values in an any field can be boolean or integer or unsigned or double or number or decimal or string or varbinary – or array or map or tuple. Examples: true, 1, 'xxx', {box.NULL, 0}.
"
This will be (I hope) easy for all of us.

[NickVolynkin]

@pgulutzan and @alexandra-mara, thank you for all the good work. I've just merged the PR.

I made a mistake with the first merge and had to re-merge it.. twice. As a result, the commit is made under my name, but I've explicitly stated the authorship of the original text and the translation. I apologize for the inconvenience this might have caused.

[pgulutzan]

@NickVolynkin, for me that is the opposite of inconvenient, since I guess it means we have now finished with this pull request and I will be able to close all the related issues assigned to me -- except issue#2151, since as discussed with @igormunkin above I have a few more words. See issue#2235 Fixes gh-2151 UUID is now part of SCALAR.