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

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