5 ms·

Is the headline true at all? It was punted to the next commitfest on 2/1. It could easily keep getting punted like it has been for a ~year now.

coldtea 3y ago
Is it that hard to implement? Supporting an additional UUID version in PostgreSQL sounds like the most trivial change to implement (compared to anything that touches core backend, table management, replication, query schedulling, and so on).
- lordgilman 3y ago
  The patch is already written, it's on that page. The bottleneck in Postgres is reviewer bandwidth which is why it's been moved out of several commitfests.
  - pgaddict 3y ago
    I don't think reviewer bandwidth is the main issue for this patch. It's a 200-line change (considering C code, there's more in docs/tests), and the code is not overly complicated / sensitive (in the sense that it's very isolated and unlikely to break random stuff). For me the main challenge was that it's still considered a draft (AFAIK). It may be unlikely to change, but if it does I'd rather not have to deal with persistent UUIDv7 data generated per some previous spec. Also, if I really want/need UUIDv7, it's not that hard to create an extension that generates UUID in arbitrary ways, including the proposed v7.
    - x4m 3y ago
      +1 there's already well maintained extension https://github.com/fboulnois/pg_uuidv7 https://github.com/fboulnois/pg_uuidv7 It's slightly different from recommendations by draft RFC version (there's no counter), but fully within spec requirements. From practical point there's no difference at all.
- asabil 3y ago
  The UUID spec update has not been finalized yet. It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly. EDIT: here is the IETF working group page https://datatracker.ietf.org/wg/uuidrev/about/ https://datatracker.ietf.org/wg/uuidrev/about/ Their milestone seems to submit the final proposal by March.
  - Rafert 3y ago
    > It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly. The chances of that seem extremely low at this point. The contents of a version 7 UUID have not changed since work started on RFC 4122 bis in October 2022: https://author-tools.ietf.org/iddiff?url1=draft-ietf-uuidrev-rfc4122bis-00&url2=draft-ietf-uuidrev-rfc4122bis-14&difftype=--html#:~:text=implementation.-,5.7.%20%20UUID%20Version%207,-5.7.%20%20UUID%20Version https://author-tools.ietf.org/iddiff?url1=draft-ietf-uuidrev...
    - pgaddict 3y ago
      The chances may be low, but either it's a draft or a final version. There's clearly little pressure to rush this, considering it's not difficult to add a custom function generating UUIDv7 ...

coldtea 3y ago

Is it that hard to implement? Supporting an additional UUID version in PostgreSQL sounds like the most trivial change to implement (compared to anything that touches core backend, table management, replication, query schedulling, and so on).

lordgilman 3y ago
The patch is already written, it's on that page. The bottleneck in Postgres is reviewer bandwidth which is why it's been moved out of several commitfests.
- pgaddict 3y ago
  I don't think reviewer bandwidth is the main issue for this patch. It's a 200-line change (considering C code, there's more in docs/tests), and the code is not overly complicated / sensitive (in the sense that it's very isolated and unlikely to break random stuff). For me the main challenge was that it's still considered a draft (AFAIK). It may be unlikely to change, but if it does I'd rather not have to deal with persistent UUIDv7 data generated per some previous spec. Also, if I really want/need UUIDv7, it's not that hard to create an extension that generates UUID in arbitrary ways, including the proposed v7.
  - x4m 3y ago
    +1 there's already well maintained extension https://github.com/fboulnois/pg_uuidv7 https://github.com/fboulnois/pg_uuidv7 It's slightly different from recommendations by draft RFC version (there's no counter), but fully within spec requirements. From practical point there's no difference at all.
asabil 3y ago
The UUID spec update has not been finalized yet. It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly. EDIT: here is the IETF working group page https://datatracker.ietf.org/wg/uuidrev/about/ https://datatracker.ietf.org/wg/uuidrev/about/ Their milestone seems to submit the final proposal by March.
- Rafert 3y ago
  > It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly. The chances of that seem extremely low at this point. The contents of a version 7 UUID have not changed since work started on RFC 4122 bis in October 2022: https://author-tools.ietf.org/iddiff?url1=draft-ietf-uuidrev-rfc4122bis-00&url2=draft-ietf-uuidrev-rfc4122bis-14&difftype=--html#:~:text=implementation.-,5.7.%20%20UUID%20Version%207,-5.7.%20%20UUID%20Version https://author-tools.ietf.org/iddiff?url1=draft-ietf-uuidrev...
  - pgaddict 3y ago
    The chances may be low, but either it's a draft or a final version. There's clearly little pressure to rush this, considering it's not difficult to add a custom function generating UUIDv7 ...