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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Baji Shaik <baji(dot)pgdev(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-24 17:46:54
Message-ID: CAD21AoBpCg6u8wzQ3hGLbxsrn6sBkkdBXuZkgpEH+rZRSxLn6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Fri, Jun 12, 2026 at 3:35 PM Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> 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.

Thank you for creating the patches!

Here are some review comments:

+ /*
+ * Reject infinite intervals. timestamptz_pl_interval() can produce an
+ * infinite timestamp when the input interval is infinite, and converting
+ * that to a Unix epoch value would overflow.
+ */
+ if (TIMESTAMP_NOT_FINITE(ts))
+ ereport(ERROR,
+ (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("timestamp out of range for UUID version 7"),
+ errdetail("UUID version 7 does not support infinite
timestamps.")));
+

I think we can do this check earlier, like before shifting the
timestamp, and we can mention in the doc that we don't accept
'infinity' and '-infinity' values.

---
+ /*
+ * The UUID version 7 timestamp field is 48 bits wide, storing
+ * milliseconds since the Unix epoch. Reject timestamps that would
+ * overflow this field (dates beyond approximately year 10889).
+ */
+ if (us / US_PER_MS > (int64) 0xFFFFFFFFFFFF)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATETIME_VALUE_OUT_OF_RANGE),
+ errmsg("timestamp out of range for UUID version 7"),
+ errdetail("UUID version 7 does not support timestamps
beyond approximately year 10889.")));

Please use INT64CONST() instead.

---
I think we need to mention in the doc that timestamp shifting beyond
the range UUIDv7 can support is not accepted.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tristan Partin 2026-06-24 17:58:02 Re: uuidv7 improperly accepts dates before 1970-01-01
Previous Message Etsuro Fujita 2026-06-24 17:02:41 Re: BUG #19484: Segmentation fault triggered by FDW

Browse pgsql-hackers by date

  From Date Subject
Next Message Tristan Partin 2026-06-24 17:50:30 Re: Add MIN/MAX aggregate support for uuid
Previous Message Paul A Jungwirth 2026-06-24 17:21:26 Re: FOR PORTION OF should reject GENERATED columns