Re: uuidv7 improperly accepts dates before 1970-01-01
Baji Shaik <baji.pgdev@gmail.com>
From: Baji Shaik <baji.pgdev@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: zsolt.parragi@percona.com, pgsql-hackers@lists.postgresql.org
Date: 2026-06-25T13:47:27Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- v3-0002-Reject-pre-epoch-timestamps-in-uuidv7-interval.patch (application/octet-stream) patch v3-0002
- v3-0001-Reject-infinite-intervals-in-uuidv7-interval.patch (application/octet-stream) patch v3-0001
- v3-0003-Reject-timestamps-beyond-48-bit-limit-in-uuidv7-i.patch (application/octet-stream) patch v3-0003
On Wed, Jun 24, 2026 at 9:19 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > From a user's perspective, it seems sufficient to know that the > shifted timestamp falls outside the range supported by UUID v7. As a > translator, I'm not particularly enthusiastic about adding more > message variants when the distinction is not particularly useful to > users. > Thanks for the feedback, Kyotaro. Good point. Attached v3 with all boundary checks using a single shared errdetail: "UUID version 7 supports timestamps from 1970-01-01 to approximately year 10889." 0001 - Reject infinite intervals 0002 - Reject pre-epoch timestamps (with overflow-safe epoch conversion) 0003 - Reject timestamps beyond the 48-bit limit I prefer keeping them as 3 patches since each addresses a distinct failure mode and is easier to review/bisect independently. That said, since 0002 and 0003 now share the same errdetail and are logically the same validation (timestamp outside valid range), I'm happy to merge them into one patch for v4 if preferred. Thanks, Baji Shaik.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
COPY TO FORMAT JSON: respect column list order
- effb923d9dec 19 (unreleased) landed