@panarch

https://en.wikipedia.org/wiki/Universally_unique_identifier

UUID is not just a random number.
You can use uuid v4 for this case.
https://docs.rs/uuid/0.8.2/uuid/

Are you referring to 128 bit ones?
Else how do they differ?

Should I perhaps rename this to UUID_SHORT? (See linked issue)

What I mean is, it is more common to use text representation for UUID.
You can really simply use uuid 4 from the crate.

We would need a new data type if we want to do that reasonably.
It would be unreasonable to waste space and enable a lot of functions which we don't want to allow on UUID; it isn't text, it is a u128, which is often formatted, for readability, as groups of hexadecimal text.

UUID data type and UUID function is just a different independent issue.
In this pr, what we are talking about is UUID function, so let's focus on the issue only.

Exactly, which is why I have opted to make an implmentation of UUID_SHORT for now which we can reasonably represent with an existing datatype, specifically i64 (short one bit for the signing, hence the wrap around of allowing negatives as values) or INTEGER.

Was this issue for implementing UUID?
And I don't think that is a good idea to use name UUID_SHORT which generates i64.

https://tools.ietf.org/html/rfc4122

A UUID is 128 bits long, and can guarantee uniqueness across space and time.

Was this issue for implementing UUID?
And I don't think that is a good idea to use name UUID_SHORT which generates i64.

https://tools.ietf.org/html/rfc4122

A UUID is 128 bits long, and can guarantee uniqueness across space and time.

As mentioned in #196, MySQL implements UUID_SHORT which is 64 bits long.

As we have agreed this PR isn't for adding another data type thus it will not include a full length (128 bit) UUID.

I am opposed to implementing UUID as TEXT.

Thus, shall I rename to UUID_SHORT or shall we temporarily accept a short form of UUID until we implement a UUID, Bytes, Binary or other data type?

Even MySQL UUID generates text format.

I am opposed to implementing UUID as TEXT.

That's the point.
I'm definitely for UUID() to generate text.
And I'm opposed to use UUID_SHORT like non standard names.
For generating random numbers, I think it is enough to implement and use RAND - generate floating point number between 0 - 1 function which is also quite common in many other languages.

Storing it as text seems very silly to me. If it is the standard perhaps GlueSQL should do it though.

And I'm opposed to use UUID_SHORT like non standard names.

Why?
As in you intend to stick strictly to ANSI?

Storing it as text seems very silly to me. If it is the standard perhaps GlueSQL should do it though.

And I'm opposed to use UUID_SHORT like non standard names.

Why?
As in you intend to stick strictly to ANSI?

No, because UUID_SHORT is not UUID, it is just a different type of f64 random number.

Except for user documentation purpose, I usually hate to leave comments to codes.
Both compiler and human checks the codes whether it is ok or not.
However, comments are just extra information.
Programmer needs to manage comments not to be outdated, but it is quite tough.
Codes just run and pass tests, it does not care whether comments is correct or not.

A lot of mistake happens on this comments.
Usual case is, someone update existing codes but forgets to update comments to fit to the code changes.
Then, comments contain wrong information and it becomes just a mess.

In here, the comments which you wrote are already outdated.

• inserting RAND() float value to INTEGER type.
• id INT with DEFAULT UUID()
  These are not to blame, I just wanted to say how dangerous comments can be.

I hope that this can be helpful enough for you.
It is ok to do more talk in here.
Or if you are ok with this opinion, then you can remove all comments including // Unreliable result.

The issue is, the alternative to leaving comments is just to remove stuff. This way when the issues are fixed, how do we know what to re incorportate?

The issue is, the alternative to leaving comments is just to remove stuff. This way when the issues are fixed, how do we know what to re incorportate?

If you care about this, you can register the issue on this.

How would make such an issue, referring to an unmerged PR, reference it?
Surely issued would get messy if they included these sorts of things?

 /*
( Cannot test, see #197
  "INSERT INTO test (id) VALUES (RAND()), (RAND()), (RAND()), (RAND()), (RAND())",
  Ok(Payload::Insert(5)), // Should error if UUID isn't working
),
(
    "INSERT INTO test (id) VALUES (RAND())",
    Ok(Payload::Insert(1)), // Should error if UUID isn't working
),*/

/*( Cannot test, see #197
    "CREATE TABLE test_default (id INT UNIQUE NOT NULL DEFAULT RAND())",
    Ok(Payload::Create),
),
("INSERT INTO test_default (id) VALUES (NULL)", Ok(Payload::Insert(1))),
(
    "SELECT 1 FROM test_default WHERE id > 0 AND id < 1", // Unreliable result
    Ok(select!(
        id
        Value::I64;
        1
    )),
),*/

btw, I cannot even understand what is these comments for.
Why does the comment say UUID which is RAND test case?
id is INT and RAND() generates float, it is not a valid query.

"CREATE TABLE test_default (id INT UNIQUE NOT NULL DEFAULT RAND())", ,this also cannot happen. INT for DEFAULT RAND().

If it is clear enough then you will be able to register the issue.
However, for now I cannot say how to make an issue because I don't know what you want to do after.

That code is essentially pseudo-code, as you said with comments, you don't get them compiled so nothing tells you to fix them.

They're just showing tests that I want in very crude ways.

What I'm saying is that these issues relate wholly to this PR, they would not make sense as seperate issues in the gluesql github, as there is nothing that can be done for them as the repository stands.

Having said that however, once this PR is merged there will be actions that could be taken.
Hence my asking whether it would be reasonable to add such issues to this GitHub repository.