You mean like JOIN othertable ON thistable.id=othertable.id WHERE thistable.id = 'foo'?

> How would a later datalog query engine for core2 work without that? A Datalog->SQL compiler (like https://github.com/EvgSkv/logica) would probably work like that. If you're curious about how our existing Datalog-on-Core2 spike maps to the internal representation (IR) then you could try playing with this ns: https://github.com/xtdb/core2/blob/master/test/core2/datalog/datalog_test.clj

I mean just like you can do nested pulls SELECT post.title, post.author.firstname, post.author.lastname FROM post where you wouldn’t need to explicitly join an author table, as the “author” attribute of the post would be a link to a author doc

and the author would be a link, not nested data in the post “table”

but yeah, I’ll check out the datalog->sql compiler, thanks for the link

in xtdb1 and datalog I can just “join” any type of entity, as the attribute value is the :xt/id I don’t need to encode that “this id number refers to this table” in the query

Ah I see, well with Core2 you could go quite far with having all data in a single "universal" table if you really want, such that you don't need to reason in terms of tables at all and all joins can be self-joins. However short of doing that - and there would invariably be some performance/expressiveness downsides to that pattern - I expect you could use CTEs to paper over some of the more gnarly join constructions and simplify some queries. Further down the road we would like to implement https://www.iso.org/standard/79473.html?browse=tc (currently still only a "draft")

> I mean just like you can do nested pulls SELECT post.title, post.author.firstname, post.author.lastname FROM post where you wouldn’t need to explicitly join an author table, as the “author” attribute of the post would be a link to a author doc I wouldn't rule out for this specific example though that there may yet be an XT-specific SQL extension we create to make something a bit more convenient like this possible (similar to how we plan to pull in other schemaless SQL ideas from https://partiql.org/assets/PartiQL-Specification.pdf etc.) Broadly speaking though we hope to implement the standard well enough that more advanced tooling and other/existing ergonomic abstractions can be built atop. I'm 100% just playing here, imagining; SELECT post.title, post{author, author}.firstname, post{author, author}.lastname FROM post

for me, part of the appeal of datalog is having just entities that can link to other entities, instead of thinking in tables