I see last push went from intXstore -> mi_intXstore and then didn't bigendian fail like this test failure - something I could watch out for other BE test fails.

Hello @StefanoPetrilli.

I'm preparing a branch with UUIDv4() for testing by our QA team.
While working on it I realized there was a wrong inheritance in MariaDB class hierarchy:
UUID() erroneously inherited some VARCHAR features from SYS_GUID(), which should not happen.

I reported this problem as:
https://jira.mariadb.org/browse/MDEV-33827 - UUID() returns a NULL-able result
which is now fixed in 11.5.

This is the patch:
9b02b7c

The class Item_func_uuid now derives from something else than Item_func_sys_guid.

Unfortunately, I had to duplicate these methods responsible for non-deterministic behavior:

 bool const_item() const;
 table_map used_tables() const;
 bool check_vcol_func_processor(void *arg);

But this change guarantees that the functions UUID(), UUIDv4(), and UUIDv7() soon, have exactly the same behavior with all other SQL expressions returning UUID, like table columns and CAST(expr AS UUID).

After fixing MDEV-33827, I cherry-picked your patch again.
Then pushed two patches on top of it: they are marked as "Fixup" and "Fixup 2" in their commit comments.

Please have a look into this branch:
https://github.com/MariaDB/server/commits/bb-11.5-bar-MDEV-11339/

"Fixup" addresses the things we came up during discussions with the team (Daniel Black and Sergey Golubchik):

• We don't need the code from my_uuid_v4.c in the server (at least at this point). So it was moved to plugin/type_uuid/, into a new class UUIDv4.
• A failure in my_random_bytes() should not raise an error. A warning with a fallback should be OK instead.

"Fixup 2" additionally introduces a template Item_func_uuid_vx, to share as much as possible code between UUID() and UUIDv4() and the coming soon UUIDv7().

Do you agree with these additional changes? Do you have any suggestions for further improvements?

Note, I'm going to squash the "Fixup" commit into your main commit, if you don't mind. It will remain with your authorship.

Hello @abarkov,

My only comment is that falling back to UUIDv1 in case of entropy error might not be the most appropriate choice. If I try to generate a UUIDv4 I would rather get an error than a UUIDv1 because they have different properties and is not what I asked for.

What do you think?

Hi @StefanoPetrilli,

We discussed with Sergei again.
Although, we think that the likelihood of the situation with a my_random_bytes() failure is near to 0,
still we're feeling somewhat not comfortable about raising the error, which will rollback the entire current transaction.

What about another possible solution:

 static void construct(char *to)
  {
    if (my_random_bytes((uchar*) to, 16) != MY_AES_OK)
    {
      push_warning_printf(current_thd, Sql_condition::WARN_LEVEL_WARN,
                          ER_UNKNOWN_ERROR,
                          "Failed to generate a random value for UUIDv4");
      /*
        This is very unlikely situation when my_random_bytes() fails.
        Let's fallback to my_rnd().
      */
      for (i=0; i < 4; i++)
        int4store(&buf[i*4], my_rnd(&sql_rand)*0xFFFFFFFF);
    }
    /*
      We have random bytes at to[6] and to[8].
      Let's inject proper version and variant to make it good UUIDv4.
    */
    inject_version_and_variant(to);
  }

Note, sql_rand is a global seed declared in sql/mysqld.cc.
The above code will likely additionally need a mutex lock around the loop with my_rnd().
What do you think about this version otherwise?

Hello @abarkov,

I agree that the probability of an error is close to zero and for this reason I think both versions would be acceptable but personally, I like your last version more.

Thanks @StefanoPetrilli very much for the contribution and making the base.

I'm closing this now per MDEV the current version is bb-11.5-bar-MDEV-11339 and is undergoing testing for 11.6.