Hacker News Reader

Hacker News

Comment by djbusby | Hacker News Reader

Parent Full thread

djbusby

I would use a ULID rather than thread ID.

https://github.com/ulid/spec

They (and others) are great for this kind of case - and many others.

View on HN

ulid is great, I use it a lot.

There is also a draft to make a new uuid variant – uuid v7 – that will be very similar to how ulid works.

https://www.ietf.org/archive/id/draft-peabody-dispatch-new-u...

I use ULID a lot too and It’s frustrating how close the new spec UUIDs are to it without actually being the same… so I’ve got a bunch of code to modify once Postgres supports generation of the new UUIDs server side without extensions or stored procedures. Relatively painless work, but frustrating since it could have been avoided.

Yes. V7 looks good but ULID already does it. Rather than change code, I'm just staying with ULID. All give us 128 bits. That should be enough for anyone ;/

> frustrating since it could have been avoided.

How? UUID is a structured format so the only options I can see is ulid creating their own unregistered uuid variant (probably a terrible idea) or adding ulid support to postgres (nothing to do with uuid).

I'd love for Postgres to adopt ULID as a first class variant of the same basic 128bit wide binary optimized column type they use for UUIDs, but I don't expect they will, while its "popular" its not likely popular enough to have support for them to maintain it in the long run... Also the smart money ahead of time would have been for the ULID spec to sacrifice a few data bits to leave the version specifying sections of the bit field layout unused in the ULID binary spec (https://github.com/ulid/spec#binary-layout-and-byte-order) for the sake of future compatibility with "proper" UUIDs... Performing one quick bitfield modification on every row in PostgreSQL would have been less painful as in set bit, vs load parse, repack in order to re-computing the appropriate UUIDv7s (or UUIDv8s for some reason) since the primary key update transaction should be roughly the same speed either way.

ULIDs technically fall under UUID v8 since they map onto the 128bit space. So it's possible that you can just keep using them and PostgreSQL might have something for v8 specifically.

I haven’t had my coffee yet but I’m pretty sure v8 still needs to set the version bits to specify its a v8 UUID, which means there’s 6 bits of data that need to be thrown away to migrate from ULID to a fully conforming UUID.

Reply on news.ycombinator.com