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

From: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: uuidv7 improperly accepts dates before 1970-01-01
Date: 2026-06-12 22:34:59
Message-ID: CA+fm-RN4eMEr2tzZU_mAV-=WfdmPXJ4Ea_GpmSS8=yStSy8onQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Jun 11, 2026 at 2:20 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:

> I think we should go ahead and add both upper and lower bound checks,
> barring objections.
>

Thanks Masahiko. Here's a patch series that adds both boundary
checks along with the infinity check from my earlier patch:

0001 - Reject timestamps before the Unix epoch (lower bound)
0002 - Reject infinite intervals
0003 - Reject timestamps beyond the 48-bit field limit (upper bound)

Christophe's original v1 covered the pre-epoch case; 0001 is
essentially the same fix with slightly different wording. I have
included it here so the series is self-contained and applies
cleanly on HEAD. Happy to drop it in favor of Christophe's
version if you prefer that.

The infinity check (0002) goes before the epoch conversion so
that uuidv7('infinity'::interval) gets a clear "infinite timestamps"
message rather than falling through to the pre-epoch check
with a confusing detail.

All three use ERRCODE_DATETIME_VALUE_OUT_OF_RANGE with errdetail.

Thanks,
Baji Shaik.

Attachment Content-Type Size
0001-Fix-uuidv7-with-pre-epoch-interval-silently-producin.patch application/octet-stream 3.0 KB
0002-Fix-uuidv7-with-infinite-interval-causing-integer-ov.patch application/octet-stream 3.2 KB
0003-Fix-uuidv7-with-far-future-interval-silently-overflo.patch application/octet-stream 3.1 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-06-13 00:52:09 Re: BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.
Previous Message PG Bug reporting form 2026-06-12 19:19:31 BUG #19518: Path resolution for loading a function fails, if postgres is somewhere in the path.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-06-12 22:39:38 Re: BackgroundPsql swallowing errors on windows
Previous Message Zsolt Parragi 2026-06-12 22:30:33 Re: [PATCH] Fix PITR pause bypass when initial XLOG_RUNNING_XACTS has subxid overflow