Re: uuidv7 improperly accepts dates before 1970-01-01 - Mailing list pgsql-bugs

From Andrey Borodin
Subject Re: uuidv7 improperly accepts dates before 1970-01-01
Date
Msg-id 966B5430-8ECD-48FA-B56F-22452D9CDBBF@yandex-team.ru
Whole thread
In response to uuidv7 improperly accepts dates before 1970-01-01  (Christophe Pettus <xof@thebuild.com>)
List pgsql-bugs

> On 25 Apr 2026, at 05:19, Christophe Pettus <xof@thebuild.com> wrote:
>
> "Don't do that" is one answer, but for good hygiene, here's a patch that adds a < 0 check and a regression test.

Hi Christophe!

We intentionally left ability to overflow unix_ts_ms bits. In some cases one might want to
intentionally break time locality by using construction like SELECT uuidv7(INTERVAL '1000 years' * shard_id);
This will give time locality for UUIDs generated on each shard. We consulted with RFC authors
about this feature, and they confirmed that shifting time is compliant with RFC wording.
We wrote the specific test that ensures vast space for shift, but not unlimited.

Time shifting would become a footgun if we throw an exception when overflown.
If you use SELECT uuidv7(INTERVAL '-1000 years'); for generating identifiers, they will still be unique and
time-local, and more over - they will be ascending for a single backend. So no documented guarantees
are broken.

Thank you!


Best regards, Andrey Borodin.


pgsql-bugs by date:

Previous
From: Ayush Tiwari
Date:
Subject: Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor