4 ms·
Well UUIDv7 can be consumed as a UUIDv4 in the same way, its just 16 bytes. The point of the standard is to define how the particular bytes are chosen.
by jeremyjh 3y ago
Well UUIDv7 can be consumed as a UUIDv4 in the same way, its just 16 bytes. The point of the standard is to define how the particular bytes are chosen.
- pphysch 3y agoThe latest standard for v7 does not meaningfully describe how to interpret the last segment. It says they could be pseudorandom and non-monotonic. Or it could be monotonic and non-random. These are completely disjoint cases! "X or not X" is tautological. And there is no way to determine which (e.g. there could be a flag that indicates this mode, but there is not). To be clear, the standard should be amended to resolve this ambiguity. Say the last bits MAY be monotonic or MAY be pseudorandom. Or add a flag that indicates which. As there is currently no standard way to interpret these bits, I feel perfectly justified in using the a few of the least significant ones to encode additional information.
- dralley 3y agoPostgresql doesn't care, it's not going to "interpret" those bits, it is just a 128-bit integer.
- pphysch 3y agoAnd I'm glad for it, because I could implement this without needing an extension or update to PostgreSQL.
- jeremyjh 3y agoI think the purpose of the standard is so that different software implementations work the same way, so that once you've picked a standard, you can use it everywhere and know that keys are assigned the same way regardless of which software stack is generating a particular key. Its not so that systems can "interpret" it. Obviously they are your bytes to use however you want if you are rolling your own generator.
- pphysch 3y ago> you can use it everywhere and know that keys are assigned the same way regardless of which software stack is generating a particular key. But even if you follow the standard to a tee, you cannot infer anything about how the last 62 bits were assigned. That is my point!