4 ms·
It's especially tragic knowing that Postgres did originally have system-time-like versioning built-in. Instead we get to enjoy being upsold on proprietary ETL-t
by refset 3y ago
It's especially tragic knowing that Postgres did originally have system-time-like versioning built-in. Instead we get to enjoy being upsold on proprietary ETL-to-Redshift, AlloyDB, etc.
- ttfkam 3y agoCitation needed? There have been one-off, incomplete iterations in extensions, but core and contrib have never had this.
- refset 3y agoI have never researched the timeline properly to understand at which point the concept/code got ditched, but it was part of Stonebraker's 1985 vision: https://dsf.berkeley.edu/papers/ERL-M85-95.pdf https://dsf.berkeley.edu/papers/ERL-M85-95.pdf > POSTQUEL allows users to save and query historical data and versions. By default, data in a relation is never deleted or updated. Conventional retrievals always access the current tuples in the relation. Historical data can be accessed by indicating the desired time when defining a tuple variable. I looked this up during another thread which also has some other sources if you want to dig further: https://news.ycombinator.com/item?id=37956687 https://news.ycombinator.com/item?id=37956687
- krab 3y agohttps://www.postgresql.org/docs/6.3/c0503.htm https://www.postgresql.org/docs/6.3/c0503.htm
- ttfkam 3y agoThanks! I had used 6.0. I was totally unaware this was an option at the time. For what it was worth, Postgres was dog slow back then.