Live data from Hacker News

Show HN: PRQL 0.2 – a better SQL

github.com

51–60 of 166 posts

Re: Show HN: PRQL 0.2 – a better SQL

#51
post #46
post #25

Why should I use this instead of SQL?

That's a really good question! (and one we should probably answer explicitly in the [FAQ]( https://prql-lang.org/faq/ ) rather than just implicitly) The README states that "PRQL is a modern language for transforming data — a simple, powerful, pipelined SQL replacement. Like SQL, it's readable, explicit and declarative. Unlike SQL, it forms a logical pipeline of transformations, and supports abstractions such as varia…

One benefit of SQL is that the Database Engine will do the hard work of optimizing the query plan.

Do you think the SQL complied by PRQL could be as effective and optimized by database engine as the direct-written SQL?

Re: Show HN: PRQL 0.2 – a better SQL

#53
For those interested in database query languages, it is worth knowing about Datalog, the query language behind Datomic, XTDB and Datahike: http://www.learndatalogtoday.org/

E.g. a parameterised aggregate query that retrieves the name and average rating of a film starring cast members whose names match the input names:

    [:find ?name (avg ?rating)
     :in $ [?name ...] [[?title ?rating]]
     :where
     [?p :person/name ?name]
     [?m :movie/cast ?p]
     [?m :movie/title ?title]]
To reveal the answer, click on tab labelled "3" and then "I give up!": http://www.learndatalogtoday.org/chapter/7

Re: Show HN: PRQL 0.2 – a better SQL

#54
post #27

Earlier quoted context omitted.

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

Thanks a lot for testing and opening an issue! This is now fixed and released [1]. Let us know if you still face any problems.

(We need better tests against real DBs, which is very much on our roadmap)

[1]: https://github.com/prql/prql/pull/698

Re: Show HN: PRQL 0.2 – a better SQL

#56
I wonder, why would you go for a "pipeline" of relational operations, when it's strictly weaker than allowing for a tree of operations? The way the examples seem to be written, a stack machine would subsume the existing syntax, since you first specify an operand (like "from employees") and then you specify and operation (like "filter country == "USA"), where in a stack machine an operation such as "from X" would put the relation X onto the top of stack, whereas an operation such as "filter" would then replace the top of stack with a transformed relation. This could be extended by for example "join on ..." being simply an operation consuming two relations from the top of stack and putting one result back, joining two pipelines into one.

Re: Show HN: PRQL 0.2 – a better SQL

#58

Earlier quoted context omitted.

Opened an issue as I couldn't get this to work against sqlite: https://github.com/prql/prql/issues/695

Thanks a lot for testing and opening an issue! This is now fixed and released [1]. Let us know if you still face any problems. (We need better tests against real DBs, which is very much on our roadmap) [1]: https://github.com/prql/prql/pull/698

Thank you for the amazingly quick fix!

Re: Show HN: PRQL 0.2 – a better SQL

#60

Obligatory dismissive comment: > 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!

We're definitely not ready for production! Sorry if that was implied.

But we are ready for people to start using it in their development work. Lmk if there's a better way of describing that.

Post reply on HN