> A line-break doesn't created a pipeline in a few cases: ...
> When the following line is a new statement, by starting with a keyword such as func.
This feels like it could cause compatibility issues in the future.
PRQL – A proposal for a better SQL
41–50 of 302 posts
Re: PRQL – A proposal for a better SQL
#42Do people still write SQL?
Do people still use ORMs?
Re: PRQL – A proposal for a better SQL
#43I wonder how this compares in practice to EdgeQL, https://www.edgedb.com/showcase/edgeql
Offhand i thought PRQL seemed easier to reason about, but something about EdgeQL seems better to me.. though i can't describe it.
Re: PRQL – A proposal for a better SQL
#44I've always wondered why there aren't query languages that embrace algebraic data types and pattern matching. Seems like an obvious fit to me. There's many times where you'd want to model a table that has either this scheme or that schema.
Re: PRQL – A proposal for a better SQL
#45The time of SQL alternatives https://news.ycombinator.com/item?id=30053860
Yup, I posted that yesterday too. I think Malloy is really interesting — compile to SQL but give more integrations to the DB, like schema-during-development. It has a proper team, led by Lloyd Tabb.
Re: PRQL – A proposal for a better SQL
#46No post body was provided.
Re: PRQL – A proposal for a better SQL
#47I wonder how this compares in practice to EdgeQL, https://www.edgedb.com/showcase/edgeql Offhand i thought PRQL seemed easier to reason about, but something about EdgeQL seems better to me.. though i can't describe it.
I see EdgeQL as an excellent replacement for SQL in OLTP settings — it has great language integration and a unified relational & typing approach. (Please correct me if this is mistaken though).
I wrote the PRQL proposal for analytical / OLAP queries, where the pipeline of transformations are more important, and relations and typing are relatively less important.
Re: PRQL – A proposal for a better SQL
#48I like the flow direction compared to standard SQL. SQL is supposed to read like a sentence I suppose but I have many times looked at it and really wanted things to be in a more logical order.
My main suggestion would be to be a bit less terse and introduce a bit more firm formatting. I'm not a huge fan of the term "split" and feel like jazzing that up to "split over" or even just reviving "group by" would improve readability. Additionally the aliasing could use work, I'd suggest reversing the assignment to be something closer to `use salary + payroll_tax as gross salary`. In terms of firm formatting, unless I'm missing something there isn't any reason to allow a filter statement before any aliases - so you can force two fixed positions for filter clauses which would make it always legal to reference aliases in filters.
On the brief topic of form vs. flexibility. SQL is a thing that, when complex, is written by many people over the course of its lifetime - removing the ability to make bad decisions is better than enabling the ability to write simple things even simpler - those silly do nothing queries like "SELECT * FROM customer WHERE deleted='f'` are written once[1] in a moments time and never inspected again. The complex queries are what you want to optimize for.
1. If they even are - with ORMs available a lot of those dead simple queries just end up being done through an ORM.
Re: PRQL – A proposal for a better SQL
#49Nice. Why OCaml though? I think using a more conventional language to construct queries could yield more adoption. It also seems that ORMs kinda of exist to tackle a similar issue, at least in part.
Re: PRQL – A proposal for a better SQL
#50meanwhile I'm still stuck trying to make prolog work xD