Earlier quoted context omitted.
In particular, I think this is looking pretty good and I'd want to see even more complicated examples. For example, What do window functions end up looking like? [1] What about crazy operations like calculating percentile_cont? [2] Or just in general, how would "implementation specific" queries end up looking? [1] https://www.postgresql.org/docs/current/tutorial-window.html [2] https://docs.microsoft.com/en-us/sql/t-…
Great questions! Window functions are here [1]. (We should add these to the homepage too) Implementation specific queries can be handled by the Dialect parameter [2], though there's still lots of work to do to build that out. [1]: https://prql-lang.org/book/transforms/window.html [2]: https://prql-lang.org/book/queries/dialect_and_version.html
Show HN: PRQL 0.2 – a better SQL
31–40 of 166 posts
Re: Show HN: PRQL 0.2 – a better SQL
#32Re: Show HN: PRQL 0.2 – a better SQL
#33From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?
As said, currently PRQL transpiles to SQL, so all expressions in PRQL are can be expressed in SQL. But not all SQL expression can be translated back into PRQL - some intentionally and some are just not yet implemented (UNION - i.e. vertical concat). But we also have plans for doing things that some SQL databases may not support, such as pivot (rows to columns).
Re: Show HN: PRQL 0.2 – a better SQL
#34but wish this was somehow encoded as JSON, so you could easily build pipeline UI for complex SQL Generation.
Re: Show HN: PRQL 0.2 – a better SQL
#35> 0.2
No it ain't (in production).
Anyway, this looks great. I LOVE the fact that you've provided a book too. Consider me a fan!
Re: Show HN: PRQL 0.2 – a better SQL
#36There are a lot of rough edges when building a string representing an SQL query in the programming language that you're using. You have to be careful to avoid SQL injections, for starters. Do the bindings for PRQL innovate at this level?
Re: Show HN: PRQL 0.2 – a better SQL
#37 from employees
join side:left positions [id==employee_id]
turns into SELECT
employees.*,
positions.*
FROM
employees
LEFT JOIN positions ON id = employee_id
I would love to see joins worked into the main learning examples. Without join, the examples lack a bit of the "relation" part; we could just as easily be compiling a DSL to a chain of `array.filter`, `array.reduce`, `array.map` calls. Joins are what makes relational modeling interesting!I would love to see Datalog/SPARQL-style implicit joins to make graph traversals like "which users have edited documents I own?" less verbose.
Re: Show HN: PRQL 0.2 – a better SQL
#38Re: Show HN: PRQL 0.2 – a better SQL
#39A good example might be a groupwise maximum. Those always tend to be a bit of a PITA in SQL if you're not writing them regularly. Be interesting to see what it transpiles to, as well.
If you only want maximum of one column, the PRQL is quite simple: from my_table group column_a ( aggregate (max column_b) ) If you want the row with the maximum value it gets interesting: from my_table group column_a ( sort [-column_b] take 1 ) You can read more about group here: https://prql-lang.org/book/transforms/group.html