11–20 of 28 posts
[0] https://www.splitgraph.com/docs/getting-started/introduction
Can any of you folks who have implemented something like that in Postgres recommend best practices, how to model it, tools, etc?
Why do you need the versioning_trigger on 'INSERT' also? There is no original row to archive in this case, or what does this do?
We're building something that partially overlaps with this at Splitgraph [0] (co-founder here). Instead of bitemporal tables, we're using columnar storage (cstore_fdw) + delta compression as a storage backend and support Git-like operations (commit, checkout, etc...). We also let you build datasets with a Dockerfile-like language as well as share them with other Splitgraph peers or the public Splitgraph catalog. [0]…
Why do you need the versioning_trigger on 'INSERT' also? There is no original row to archive in this case, or what does this do?
ON CONFLICT DO UPDATE
We're building something that partially overlaps with this at Splitgraph [0] (co-founder here). Instead of bitemporal tables, we're using columnar storage (cstore_fdw) + delta compression as a storage backend and support Git-like operations (commit, checkout, etc...). We also let you build datasets with a Dockerfile-like language as well as share them with other Splitgraph peers or the public Splitgraph catalog. [0]…
And a slightly off-topic observation: excellent choice of parsimonious as a grammar parser :)
What problem does this solve?
(Disclaimer: I'm coming from MariaDBs temporal table feature but this is basically the same in PostgreSQL) Temporal tables adding an additional "time axis" to SQL databases. A "valid from" and "valid to" field is added to each row and the SQL syntax is extended for allowing two new types of queries: 1. Query the data as of a specific point in time. E.g. "show all customers as of April 9th 2021". This not only limits…
We have tons of that at work, so this feature would have been nice. Currency exchange rates, dozens of official code lists (including countries!), VAT registration status of companies.
If a user makes a change to a declaration submitted at an earlier date, then the data from the original submission date must be used, so we need to keep all this around.
Alas, not using PostgreSQL.
Bitemporal history https://news.ycombinator.com/item?id=26735260
Crux: Open-source document database with bi-temporal graph queries https://news.ycombinator.com/item?id=23493163