fabiolimace/UUIDv6.sql

https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bis-14.html

does draft-14 support all of UUIDv7

Hi @productdevbook

The UUIDv7 generator here is in accordance with draft-14 section 5.7.

5.7.
UUIDv7 values are created by allocating a Unix timestamp in milliseconds in the most significant 48 bits and filling the remaining 74 bits, excluding the required version and variant bits, with random bits for each new UUIDv7 generated to provide uniqueness as per Section 6.9. Alternatively, implementations MAY fill the 74 bits, jointly, with a combination of the following subfields, in this order from the most significant bits to the least, to guarantee additional monotonicity within a millisecond:

An OPTIONAL sub-millisecond timestamp fraction (12 bits at maximum) as per Section 6.2 (Method 3).

The only exception is that the random() function is not a CSPRNG generator, as you may have noticed.

6.9.
Implementations SHOULD utilize a cryptographically secure pseudo-random number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). The exception is when a suitable CSPRNG is unavailable in the execution environment.

You have to install pgcrypto to have access to crypto functions.

Thanks for asking.

the uuid generated is not accurate, sometimes 1/10 condition

Hi @LuckyArdhika

Could you show the code used to test the accuracy?

The UUID generated by the function is accurate to the millisecond.

In the test below, I changed 2 lines of the original code. At the end there is a comparison of the millisecond in the timestamp and the millisecond embedded in the UUID.

Note that there is no significant loss of accuracy. The only difference is due to the floating-point division operation of the IEEE-754 standard.

Additionally, the microsecond variable in the function is used to add extra monotonicity, it is not intended to be precise.

-- create or replace function uuid7() returns uuid as $$                   -- ## REPLACED LINE ##
create or replace function uuid7(parameter_timestamp timestamp with time zone) returns uuid as $$
declare
	v_time timestamp with time zone:= null;
	v_secs bigint := null;
	v_msec bigint := null;
	v_usec bigint := null;

	v_timestamp bigint := null;
	v_timestamp_hex varchar := null;

	v_random bigint := null;
	v_random_hex varchar := null;

	v_bytes bytea;

	c_variant bit(64):= x'8000000000000000'; -- RFC-4122 variant: b'10xx...'
begin

	-- Get seconds and micros
--	v_time := clock_timestamp();                       -- ## REPLACED LINE ##
	v_time := parameter_timestamp;
	v_secs := EXTRACT(EPOCH FROM v_time);
	v_msec := mod(EXTRACT(MILLISECONDS FROM v_time)::numeric, 10^3::numeric);
	v_usec := mod(EXTRACT(MICROSECONDS FROM v_time)::numeric, 10^3::numeric);

	-- Generate timestamp hexadecimal (and set version 7)
	v_timestamp := (((v_secs * 10^3) + v_msec)::bigint << 12) | (v_usec << 2);
	v_timestamp_hex := lpad(to_hex(v_timestamp), 16, '0');
	v_timestamp_hex := substr(v_timestamp_hex, 2, 12) || '7' || substr(v_timestamp_hex, 14, 3);

	-- Generate the random hexadecimal (and set variant b'10xx')
	v_random := ((random()::numeric * 2^62::numeric)::bigint::bit(64) | c_variant)::bigint;
	v_random_hex := lpad(to_hex(v_random), 16, '0');

	-- Concat timestemp and random hexadecimal
	v_bytes := decode(v_timestamp_hex || v_random_hex, 'hex');

	return encode(v_bytes, 'hex')::uuid;
	
end $$ language plpgsql;

create or replace function extract_timestamp(parameter_uuid uuid) returns bigint as $$
declare
	v_uuid_hex varchar := null;
	v_timestamp bigint := null;
	v_timestamp_hex varchar := null;
begin

	v_uuid_hex := replace(parameter_uuid::varchar, '-', '');
	v_timestamp_hex := substring(v_uuid_hex, 1, 12) || substring(v_uuid_hex, 14, 3);
	v_timestamp := ('x'||lpad(v_timestamp_hex,16,'0'))::bit(64)::bigint;

	return mod(v_timestamp >> 12, (10^3)::bigint);

end $$ language plpgsql;

select statement_timestamp()::varchar ts, mod(EXTRACT(MILLISECONDS from statement_timestamp())::bigint, 1000) ms_from_ts, extract_timestamp(uuid7(statement_timestamp())) ms_from_uuid;

For postgres 9.2 compatibility you need to cast the following two values explicitly:

  v_secs := EXTRACT(EPOCH FROM v_time)::bigint;
  v_usec := mod(EXTRACT(MICROSECONDS FROM v_time)::numeric, 10^6::numeric)::bigint;

Otherwise you'll get

SQL Error [22P02]: ERROR: invalid input syntax for integer: "1707596980.41937304"
  Where: PL/pgSQL function uuid7() line 20 at assignment

Thank you, @andnorxor !

Functions updated.

Thank you for sharing your code; it truly was a lifesaver. In one of my projects I realized too late that postgresql-contrib was not installed on some legacy systems and it was nearly impossible to install it due security restrictions. But I had already based large parts of my module on UUIDs. Your function was the perfect workaround.

🚨 FIXED rounding error

Extracting epoch seconds and converting them to bigint was causing rounding errors. For example, extracting the epoch seconds from the timestamp '2024-02-12 17:49:10.827009Z' should return 1707760150, but was returning 1707760151 (+1).

To fix this, you need to truncate before converting to bigint.

See the result of this query:

select EXTRACT(EPOCH FROM '2024-02-12 17:49:10.827009Z'::timestamp)                 as seconds,
       EXTRACT(EPOCH FROM '2024-02-12 17:49:10.827009Z'::timestamp)::bigint         as seconds_bigint,    -- implicitly rounded
       TRUNC(EXTRACT(EPOCH FROM '2024-02-12 17:49:10.827009Z'::timestamp))::bigint  as seconds_truncated; -- explicitly truncated

|seconds             |seconds_bigint|seconds_truncated|
|--------------------|--------------|-----------------|
|1,707,760,150.827009|1.707.760.151 |1.707.760.150    |

The rounding issue is now fixed.

Thanks, Tobias, for letting me know about this!

I'm refactoring the functions. I hope they are more readable after refactoring.

Refactored.

When will v6 become stable, is there any news about it?

I don't know. I hope draft 14 is the last and the new RFC is finally completed.

There are no updates to the email archive:
https://mailarchive.ietf.org/arch/browse/uuidrev/

I had to cast 2^12 as numeric to get this to work in PostgreSQL version 16.2

DIV(v_gregorian_t, 2^12::NUMERIC)
MOD(v_gregorian_t, 2^12::NUMERIC)

Dude, fantastic job! \m/

An anonymous said and deleted later:

Getting ERROR: invalid input syntax for type uuid: "018d3f3b-4390-7375-9acd-7611c9a7c" error on some uuids generated by these functions.

The last 3 hex digits are missing in 018d3f3b-4390-7375-9acd-7611c9a7c???.

For this error to occur inside the function, the following condition must be true for some return of random(), but I didn't find any value that would cause this.

select length(to_hex(((random()::numeric * 2^62::numeric)::bigint::bit(64) | x'8000000000000000')::bigint)) < 16;

I think rand_b can be split into two 32-bit random(), just in case of another floating point issue.

Instead, I just removed the decode() and encode() operations because they are no longer needed.

Diffs:

-	v_output_bytes := decode(v_gregorian_t_hex_a || v_gregorian_t_hex_b  || v_clock_sequence_and_node_hex, 'hex');
- 	return encode(v_output_bytes, 'hex')::uuid;
+ 	return (v_gregorian_t_hex_a || v_gregorian_t_hex_b  || v_clock_sequence_and_node_hex)::uuid;

-	v_output_bytes := decode(v_unix_t_hex || v_rand_a_hex || v_rand_b_hex, 'hex');
-	return encode(v_output_bytes, 'hex')::uuid;
+	return (v_unix_t_hex || v_rand_a_hex || v_rand_b_hex)::uuid;

Thanks any way, anonymous!

v_rand_b := random()::numeric * 2^62::numeric;

This line wants to produce 62 random bits, but a double between 0 and 1 only has 52 bits in the mantissa. Casting it to numeric doesn't give you more bits of entropy.

You need to do something like:

-- Generate a random 64-bit integer
create or replace function random_bigint() returns bigint as $$
declare
    hi bigint;
    lo bigint;
begin
    -- generate a number from 0 to 4294967295 inclusive
    hi := (random() * 0x100000000)::bigint;
    lo := (random() * 0x100000000)::bigint;
    return (hi << 32) | lo;
end;
$$ language plpgsql;

You are right @eloff. I missed the mantissa detail.

Replaced all numeric data types with bigint or double precision. I was using numeric to resist IEEE 754 floating point arithmetic, but this resistance is futile.

Here are the diff lines related to the variable v_rand_b:

- 	v_rand_b := random()::numeric * 2^62::numeric;
+ 	v_rand_b := trunc(random() * 2^30)::bigint << 32 | trunc(random() * 2^32)::bigint;

I think the functions are simpler now (and maybe faster).

Thank you for letting me know! 👍

hey,
ive got the biggest noob question and i am sorry to pollute this gist with it. but ...

i've created the function. ie just executed the `uuid7' sql above.
then i added the function to my prisma.schema like this:

model User {
  id          String  @id @default(dbgenerated("uuid7()"))

but trying to deploy that i get:

ERROR: function uuid7() does not exist

i get the sense that i have to turn this into an extension?!
whats wrong with my approach?

ill show myself back into my skill-issue corner.

I'm the biggest noob in prisma. Sorry.

But it looks like a search_path problem. Check these issues:

• prisma/prisma#7709
• prisma/prisma#14662 (comment)

EDIT:

• prisma-extension-uuid7: https://snyk.io/advisor/npm-package/prisma-extension-uuid7#package-footer

Performance validation for UUIDv7 implemented using SQL in PostgreSQL v16 (Monday, July 8, 2024)

https://www.dbaglobe.com/2024/07/performance-validation-for-uuidv7.html

Choosing Primary Key Type in PostgreSQL (June 23, 2022)

https://shekhargulati.com/2022/06/23/choosing-a-primary-key-type-in-postgres/

UUIDv7 is now in .Net 9! 🚀

https://learn.microsoft.com/en-us/dotnet/api/system.guid.createversion7?view=net-9.0

Meanwhile in Java... 🦗

https://bugs.openjdk.org/browse/JDK-8334015