Live data from Hacker News

Show HN: PRQL 0.2 – a better SQL

github.com

31–40 of 166 posts

Re: Show HN: PRQL 0.2 – a better SQL

#31

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

Window example is now on the homepage, thanks for the question: https://github.com/prql/prql/pull/692

Re: Show HN: PRQL 0.2 – a better SQL

#33
post #14

From 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).

hopefully you'll forgive my pedantry - "union all" is vertical concat - "union" without the "all" gives you the distinct list

Re: Show HN: PRQL 0.2 – a better SQL

#36
Looks fantastic.

There 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
I'm surprised that none of the examples on Github or the website deals with join. I eventually found some in the "book" here: https://prql-lang.org/book/transforms/join.html

    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

#39
post #27
post #13

A 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

Opened an issue as I couldn't get this to work against sqlite:

https://github.com/prql/prql/issues/695

Post reply on HN