Re: uuidv7 improperly accepts dates before 1970-01-01
Baji Shaik <baji.pgdev@gmail.com>
From: Baji Shaik <baji.pgdev@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Christophe Pettus <xof@thebuild.com>,
Andrey Borodin <x4mmm@yandex-team.ru>, pgsql-hackers@lists.postgresql.org
Date: 2026-05-28T01:00:50Z
Lists: pgsql-hackers
Attachments
- 0001-Fix-uuidv7-with-infinite-interval-causing-integer-ov.patch (application/octet-stream)
Hello Masahiko,
On Wed, May 27, 2026 at 7:02 PM Masahiko Sawada <sawada.mshk@gmail.com>
wrote:
> I guess it would be safer to raise an error in such cases rather than
> silently allowing wraparound. Otherwise, users might only realize that
> their UUIDv7 values are no longer sortable years down the road, which
> would be disastrous. Moreover, raising an error would be consistent
> with how PostgreSQL natively handles timestamp + interval overflows.
>
+1. I ran into the same issue while testing, specifically,
uuidv7('infinity'::interval) overflows int64 during the epoch
conversion and produces a UUID with an incorrect timestamp.
There's no valid use case for infinity as a shift offset.
I have a small patch that adds a TIMESTAMP_NOT_FINITE check after
timestamptz_pl_interval(), which catches both infinity and
-infinity. Happy to extend it to also cover the 48-bit upper/lower
bound checks if we agree on the direction.
Thanks,
Baji Shaik