| 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.
| 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 |