3 ms·
The join syntax in particular seems really clunky compared to what it could have been - it's unclear if they support joining on different column names (i.e. foo
by munk-a 3y ago
The join syntax in particular seems really clunky compared to what it could have been - it's unclear if they support joining on different column names (i.e. fooid = foo.id or even fooid = parentid) which would be really restricting if unsupported. It'd also be nice if they used the USING/ON distinction that SQL has instead of just supporting USING but calling it ON since that's a weird thing to mentally translate.
Pipe-driven SQLes have been interesting in the past but I much prefer when you start with a big-blob of joins to define the data source before getting into the applied operations - the SQL PQL produces looks like it would have really large issues with performance due to forcing certain join orders and limiting how much the query planner can rearrange operations.
- refset 3y ago> I much prefer when you start with a big-blob of joins to define the data source before getting into the applied operations That's essentially the model we've chosen for XTQL, with the addition of a logic var unification scope for even more concise joins: https://docs.xtdb.com/intro/what-is-xtql#unify https://docs.xtdb.com/intro/what-is-xtql#unify Also, anyone interested in this post-SQL space would probably enjoy this recent paper: https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf