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