Some great things in this release:
- official Jinja2 support, and a generic template interface
- native postgres fields
- uuid field
and it is an LTS. Time to get upgrading.
- official Jinja2 support, and a generic template interface
- native postgres fields
- uuid field
and it is an LTS. Time to get upgrading.
This one is good.
I kind of wish it were default for primary keys, since the number of times I got burned by having databases I couldn't easily merge (which UUIDs help a lot with) way exceeds the number of times I had performance/memory issues caused by actually using UUIDs.
This, of course, assumes that temporally-adjacent additions are related, but this seems like a common case for large data sets since they often arise from a series of measurements or transactions.
I created this account to make this reply because I imagine that someone here is expert enough to set me straight if I'm mistaken.
When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.
Performance shouldn't affect the decision to make it default, however. That would be premature optimization.
The only good reason I can think of for not making it default would be backwards compatibility.