An added benefit of using a UUID instead of some AUTO_INCREMENT is that in a distributed system, using Galera or Replication, data can be migrated between nodes and there is no data that ties or identifies a row to a specific server.

This looks like a duplicate of MDEV-4958.

There is an overlap, but not a duplicate. What I suggest though is that automatic generation of a UUID is added and that semantics are such that only a proper UUID can be inserted and that it is always generated, so in the case of an INSERT and UPDATE, NULL always has to be passed if the value is to be updated. To support this, the proposed SQL and API functions for retrieving the last generated UUID has to be added.

Indeed, thanks for the clarification

Now, when one can specify DEFAULT UUID() for any column is this feature still necessary?

Hello Sergei,

Is the value for last_insert_id , the PK or UNIQUE KEY default or always auto increment ?
see
MDEV-10014
MDEV-10422

/svar

last_insert_id is for auto increment only. INSERT ... RETURNING is a separate task

A column type could still be a good idea:

• output formatting (shows uuid as string, but stores in a binary format)
• rearange the uuid to make it increasing when on the same machine (put the timestamp in the end in reverse order) to be friendlier for B-Tree storage.
• maybe do something smart with secondary indexes, don't put the mostly-static part (when running on one machine) in de index?

dveeden that looks like existing UUID_SHORT and it should work the same !

serg without a way to fetch what was inserted it make this feature less attractive .The requirement that the field is facing today, is sometime to get read of auto increment. I appreciate the good step forward still , but will not make some of our clients move to 10.2. I will continue living with ugly triggers and ROW base login.

Can the DEFAULT overwrite
the auto_increment defining both on the same column , in such case teh last_isert_id would return what default is picked ?

dveeden, UUID column type is MDEV-4958. This issue is about auto-setting it to the new uuid() value, much like auto increment works. And I suggest that this special auto-setting treatment for columns of UUID type is no longer needed, because one can write DEFAULT UUID(). UUID column type itself it still useful, yes.

stephane@skysql.com, returning the last generated uuid value was not part of this issue. And DEFAULT UUID() does not solve it either. It's a completely separate issue that does not affect whether this MDEV-6445 shall be closed or not.

Sergei i'm quoting 2 sentences from this issue

• "To make this work, we need to add a mysql_last_uuid() function and a LAST_UUID SQL function added."
• "For distributed systems"

So may be this issue closing should be blocked by some missing additional task ?

let's consider this part of INSERT ... RETURNING task

Great news thanks