6 ms·
Does this stay compatible with the old uuid column type, as uuidv7() uses the same 128 bit format as gen_random_uuid()? That would mean it's easy to update old
by naranha 3y ago
Does this stay compatible with the old uuid column type, as uuidv7() uses the same 128 bit format as gen_random_uuid()?
That would mean it's easy to update old apps, as we would only have to change the default value for the columns.
- pgaddict 3y agoYes, internally it's the same as every other UUID (16 bytes, passed by reference). There's no reason to store / represent it differently.
- mplanchard 3y agoYes, we have already updated our in-app UUID generation to use v7 UUIDs and are storing them in regular postgres UUID columns (postgres 14). Works great!
- ghusbands 3y agoNote that, as jmull says in https://news.ycombinator.com/item?id=39262286 https://news.ycombinator.com/item?id=39262286 , embedding timestamps in every uuid can potentially expose private information.
- mplanchard 3y agoYes, you can check UUIDs to see if they’re v7, and extract the timestamp if so. This seems to me less problematic in most cases than being able to guess the next ID (as is the case with numeric IDs). At least for us, anybody with access to the ID also has access to the time the record was created, so there’s no new information being exposed. It’s a good thing to keep in mind though for sure.
- Merad 3y agoYes, you can use v7 today with uuid columns, you just need to add a custom function (or the more performant pg_uuidv7 extension) to generate them.