This is something that is incredibly useful. I built a system like this a while back that also adds versioning to each time period. The use case is this: let’s say you are tracking your state’s sales tax rate. You do not control this and data entry is manual so it is error prone. The rate is updated typically annually but sometimes more frequently. Let’s say for 2026 you have it at 7.25% and you entered that into the…
Yeah, I think folks that under appreciate this new functionality look at the approaches that existed and say "That works, we could just sorta, wrap that in a function" but when you start getting into useful and entangled data the overhead of implementing proper bounds checking on ranges when you're more focused on the preservation of the linkages to existing data - it gets complicated quickly. This feature doesn't ma…
My hope is that Postgres making this kind of thing a first class citizen feature will mean that ORMs and other tooling incorporate it in a standard way so that developers can internalize using it. I am sure it will take time but this is a big step. Doing all this has been possible but having standardized tooling and frameworks would be nice.
Another alternative I have used is basically having a current state table and a migrations table that get applied at a specific time. The migrations table act as both a history and a set of scheduled updates. The trick is that you have to apply the migrations and so you don’t have perfect atomic changes without some sort of locking system and timing might be off. But it is a decent system that also works.