Re: uuidv7 improperly accepts dates before 1970-01-01

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
Date: 2026-04-25 12:26:51
Message-ID: 966B5430-8ECD-48FA-B56F-22452D9CDBBF@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 25 Apr 2026, at 05:19, Christophe Pettus <xof(at)thebuild(dot)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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Ayush Tiwari 2026-04-25 10:15:31 Re: BUG #19466: Server crash (SIGSEGV) when FETCH after ALTER TYPE during open cursor