Has anyone benchmarked it or the bindings? SQL tends to be embedded directly in software programs, so building would likely happen on the fly in real-world cases.
PRQL: Pipelined Relational Query Language
111–120 of 214 posts
Re: PRQL: Pipelined Relational Query Language
#112For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…
To me it seems quite nice, but really just trivially different from SQL - like if Ruby was 'friendlier syntax that transpiles to Python', meh? You'd use whichever you happened to learn first and not bother with the other. (That's often true even though it's more than that of course.) The examples arbitrarily make SQL look more verbose: SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 Yes! Of course I'd…
I agree that I think the difficulty with the uptake will be "it's really just less annoying SQL", and it's hard to overtake a technology that's so ubiquitous when your fixes are really "nice to haves" vs something truly transformational.
That said, it's not the succinctness that's an improvement, it's that the pipelined nature of PRQL really maps much better to how people should think about queries, and also how the server executes them! Something as trivially simple as putting the from clause first means I can now get much better typeahead/autocomplete support from dev tools. Heck, I already do this now in a slightly more annoying manner: I write "select * from some_table ..." first, then I go and type out the actual columns I want because once the from clause is correct my IDE will autocomplete/show errors for possible columns.
Re: PRQL: Pipelined Relational Query Language
#113The ergonomics could be better: https://pastila.nl/?01359244/9ac65f960385a02b3193778b4c6af10... Significant newlines. Non-obvious way to specify database/schema.
There are two symbols for separating transforms in a pipeline - \n and | so you can use | instead of \n if you prefer.
So for your query from the linked gist, the following should work:
from system.numbers | select number
prql target:sql.clickhouse
from `system.numbers` | select {number}
Re: PRQL: Pipelined Relational Query Language
#114We have recently merged PRQL support into ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686 It's currently more like an experiment - I'm not sure if it will be usable or useful. There are some concerns about Rust, although minor: https://github.com/ClickHouse/ClickHouse/issues/52053#issuec...
This is awesome! Thank you!
Would that mean it would also be able to use it in clickhouse-local?
Re: PRQL: Pipelined Relational Query Language
#115For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…
To me it seems quite nice, but really just trivially different from SQL - like if Ruby was 'friendlier syntax that transpiles to Python', meh? You'd use whichever you happened to learn first and not bother with the other. (That's often true even though it's more than that of course.) The examples arbitrarily make SQL look more verbose: SELECT id, first_name, age FROM employees ORDER BY age LIMIT 10 Yes! Of course I'd…
Being able to pick the source (i.e. the FROM clause) first is useful in itself, as you then get the benefit of sensible auto-complete suggestions.
Re: PRQL: Pipelined Relational Query Language
#116Earlier quoted context omitted.
Not only PQRL fixes this. It has been allowed in ClickHouse's SQL since its inception.
That's awesome! ClickHouse is a great system by all accounts and I've been meaning to try out ClickHouse Local. I'm more familiar with DuckDB and they've also been doing some great innovation on the SQL front. I don't know offhand if they can also do the forward referencing thing but they allow putting the FROM first and having GROUP BY ALL etc.. It's great to see all this innovation happening in the SQL and Query La…
It is strange to hear about innovation in DuckDB - I see that they are gradually re-implementing the stuff already existing in ClickHouse. Sometimes they do a better job at promoting it.
Re: PRQL: Pipelined Relational Query Language
#117We have recently merged PRQL support into ClickHouse: https://github.com/ClickHouse/ClickHouse/pull/50686 It's currently more like an experiment - I'm not sure if it will be usable or useful. There are some concerns about Rust, although minor: https://github.com/ClickHouse/ClickHouse/issues/52053#issuec...
This is awesome! Thank you! Would that mean it would also be able to use it in clickhouse-local?
Yes:
clickhouse-local --dialect prql
$ clickhouse-local
:) SET dialect = 'prql'Re: PRQL: Pipelined Relational Query Language
#118I really want this to take off and become a first party supported language for Postgres. Yes, yes, relational algebra is beautiful and all that jazz. SQL is a garbage, first pass design that should have been replaced decades ago. Even Codd has complaints about it. It is amazing what he invented, but we have learned a lot about PL design since then.
Not quite what you're asking for but DuckDB has both PRQL [1] and Postgres [2] extensions, so you could probably query your Postgres database with PRQL from there.
There's also a DBeaver plugin [3] which we still need to document better and simplify the usage of but you could potentially also use that to query Postgres with PRQL.
Finally there is pyprql [4] with which you could query Postgres from a Jupyter notebook.
[1]: https://github.com/ywelsch/duckdb-prql
[2]: https://duckdb.org/docs/extensions/postgres_scanner.html
[3]: https://github.com/PRQL/prql/issues/1643
[4]: https://github.com/PRQL/pyprql
(Disclaimer: I'm a PRQL contributor.)
Re: PRQL: Pipelined Relational Query Language
#119How does this compare to EdgeQL?
This seems like just a compiler from a better language (PRQL) to SQL, while EdgeDB is actually a database that comes with not just a better language (EdgeQL), but also other great features (I love their TypeScript query builder or how incredibly frictionless the migrations are).
Re: PRQL: Pipelined Relational Query Language
#120For me the examples on the website https://prql-lang.org/ are the biggest selling point for PRQL, in particular the SQL it generates. It looks clean, straightforward, something I would've written myself. In general, I like this slightly more careful take on modern database development. 10-15 years people would start a brand new database like Mongo, or Riak, or Influx, or whatever, and would try to convince applicatio…
I don't get that - to me the examples are much less readable than SQL and I don't understand why I should want to use this. Like, yes, you can reorder the query sections, which seems to be everyone's complaint about SQL, but then you also have multiple types of brackets, colons and other syntax for no reason, all while not really accomplishing anything SQL doesn't already do. What's the attraction?
The attraction is that, especially for more complicated queries with complex joins, subqueries, aggregates, etc., that the structure of PRQL much more closely matches the "English", mental-model of the query. I can just read PRQL linearly, from top to bottom, and at each point I know what is being "pipelined" into the next phase of the query.
With SQL I have to look all over the place. And it's not just that FROM should come before SELECT, it's that if I'm doing, say, an aggregation with a group by, normal SQL doesn't really have anything to make me think about the ungrouped rows, and then merge them together to get the aggregate values. With PRQL I can just go top to bottom, and for me it's much easier to reason about (i.e. first get all the rows, then group by some specific columns, then take aggregates, etc.)
And I say this as someone who spends about half my days in SQL at present.