> which is more efficient than "hacking it" with recursive queries in a relational db
It seems to me that the way recursive CTEs were originally defined is the biggest reason that relational databases haven't been more successful with users who need to run serious graph workloads - in Frank McSherry's words:
> As it turns out, WTIH RECURSIVE has a bevy of limitations and mysterious semantics (four pages of limitations in the version of the standard I have, and I still haven't found the semantics yet). I certainly cannot enumerate, or even understand the full list [...] There are so many things I don't understand here.
Unfortunately not, I've just had this one opened in my browser for ages as a reminder (after seeing it on HN IIRC) and recognised it again in the OP instantly :)
the video demo goes to postgressql.org, all of the purchase buttons go to postgres, the get access button doesn't work, you can't schedule a demo or even contact their sales team.
"Notes and Domino is a cross-platform, distributed document-oriented NoSQL database and messaging framework and rapid application development environment that includes pre-built applications like email, calendar, etc." [0]
Lotus Notes was the original offline-first everything app, including cutting edge PKI and encryption. It worked over dial-up and needed only a handful of MBs of memory (before the Java rewrite at least). Has anything else really come close since?
Looks like DriftDB is focused on the 'system time' AS OF dimension, a.k.a. rollback querying. AsOf joins are more about doing analysis over user-defined domain timestamps (/ 'valid time'). Combining both concepts gets you a bitemporal database.
The SQL:2011 syntax puts the temporal filters directly after base table reference (and before the table alias) [0]
i.e. it would be `SELECT * FROM orders FOR SYSTEM_TIME AS OF "@seq:1000" WHERE customer_id="cust1"` rather than `SELECT * FROM orders WHERE customer_id="cust1" AS OF "@seq:1000"` (the latter being an example from the DriftDB readme)
Yes, but that’s just time traveling, IIRC. With actual time travel queries you can see what changed between T1 and T2, like “show me all users that changed their email address last month” or “of the products that changed prices, how much did they change by” etc.
You can build all of that on top of simple time travel, but there was a lot of research on how to bake it into the SQL language. IIRC, a lot of it was proposed for the SQL standard but it was too niche or something. It’s been over half a decade since I was in that space.
