PRQL – A proposal for a better SQL
github.com
PRQL – A proposal for a better SQL
1–10 of 302 posts
Re: PRQL – A proposal for a better SQL
#2I wrote this over the holidays, because I find SQL wonderfully elegant in its function, but really frustrating in its form.
Let me know any feedback — as you can see it's still at the proposal stage. If it gains some traction I'll write an implementation.
Re: PRQL – A proposal for a better SQL
#3I wrote this over the holidays, because I find SQL wonderfully elegant in its function, but really frustrating in its form. Let me know any feedback — as you can see it's still at the proposal stage. If it gains some traction I'll write an implementation.
This looks great! Clear docs and rationale, and the syntax is well thought. I'm definitely following this.
Re: PRQL – A proposal for a better SQL
#4I wrote this over the holidays, because I find SQL wonderfully elegant in its function, but really frustrating in its form. Let me know any feedback — as you can see it's still at the proposal stage. If it gains some traction I'll write an implementation.
Maybe you'd like to check FunSQL.jl, my library for compositional construction of SQL queries. It also follows algebraic approach and covers many analytical features of SQL including aggregates/window functions, recursive queries and correlated subqueries/lateral joins. One thing where it differs from dlpyr and similar packages is how it separates aggregation from grouping (by modeling GROUP BY with a universal aggregate function).
Re: PRQL – A proposal for a better SQL
#5My thought is that joins are the tough part of the SQL learning curve, but I don't see much in here that reduces the complexity of joins.
Re: PRQL – A proposal for a better SQL
#6I'm really excited about languages that build on or are compiled to SQL, in the long-term (because I think it will take a very long time to build adoption).
The ones that particularly excite me are shorthands for SQL, even though their heavy use of symbols may be a detriment. One particular use case is in easily defining static authorization policy-queries that are backed by database data plus and have request variables injected during evaluation.
I am not very excited by datalog/prolog-based languages because I think logic languages are too unnatural to ever go mainstream. But I'd be excited to be wrong or for logic languages to become more friendly.
Here are some others I'm watching.
* https://github.com/mrumkovskis/tresql
* https://www.htsql.org/doc/overview.html
* https://github.com/cytosm/cytosmRe: PRQL – A proposal for a better SQL
#7The link refers to dplyr not being able to use databases but actually there is a database backend for it in package dbplyr. See https://dbplyr.tidyverse.org/
Re: PRQL – A proposal for a better SQL
#8It would be definitely interesting to have a TypeScript of some sort but for SQL.
So a more practical and prettier syntaxe like what I'm seeing here that compiles to SQL queries.
Re: PRQL – A proposal for a better SQL
#9The syntax seems similar to Apache Pig. Both are declarative and primarily built to be a procedural form of SQL.
Re: PRQL – A proposal for a better SQL
#10It would be definitely interesting to have a TypeScript of some sort but for SQL. So a more practical and prettier syntaxe like what I'm seeing here that compiles to SQL queries.
TypeScript is more verbose than JavaScript. While I love to use TypeScript I don't think I'd categorize it as prettier than JavaScript. And practical... well if you mean it is more maintainable then yes but if you mean faster to write then no.
I don't want a more verbose SQL I want a less verbose SQL!