Our great sponsors
-
prql
PRQL is a modern language for transforming data — a simple, powerful, pipelined SQL replacement
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
dbt-core
dbt enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
-
-
postgres
Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare (by porsager)
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I appreciate the lengthy response.
I won't address every point here, but a couple of thoughts:
- To close the syntax point — I opened https://github.com/PRQL/prql/issues/3518. We're currently using the output of the rust's canonical SQL formatter. (so any claim we're obfuscating SQL's syntax is incredulous — do you agree?). I'm open to hand-written examples if SQL doesn't have sufficient auto-formatting tools available.
- "never answering (what I believed to be) substantive questions regarding extensibility and lowest common SQL denominators" — some of the features are implemented, some aren't, there are issues on GH for by-and-large all of them. Feel free to open other issues if they're not. I don't think there's a duty to respond to every question in every comment on HN, and I certainly don't think losing your composure is an appropriate response to others not answering every question.
- Many of the answers to your questions are in the docs — for example escape hatches. You don't have to read them to engage, but you could reflect on the irony of making confident claims about a project's "youthful exuberance" without having done so.
- Stepping back, are these are informed & constructive criticisms, or are they grasps for straw-men as part of a reactionary response. For example, the response takes two phrases from the website out-of-context to load a whole argument on the words "stable" & "standard". But stability & standards can each mean multiple things, and taking the least generous interpretation of a word doesn't make for a reasoned critique. Does a point such as:
touting itself as a production-ready alternative standard to SQL
Thank you.
The CLI usability was one of the aims behind [prql-query (pq)](https://github.com/prql/prql-query/). sqlite integration was on the roadmap but unfortunately that project has been largely unmaintained by me for the past 6 months. (This is just referring to prql-query and not PRQL which is under very active development.)
I'm working on a new project which will do exactly this (and a lot more!) which I hope to release next week. I'll drop the link here when that's ready.
dbt integration was one of our major goals early on but we found that the interaction wasn't as straightforward as had hoped.
There is an open PR in the dbt repo: https://github.com/dbt-labs/dbt-core/pull/5982#issuecomment-...
I have some ideas about future directions in this space where I believe PRQL could really shine. I will only be able to write those down in a couple of hours. I think this could be a really exciting direction for the project to grow into if anyone would like to collaborate and contribute!
> Automatically managed, application-transparent, physical denormalisation entirely managed by the database is something I am very, very interested in.
Sounds a bit like Noria: https://github.com/mit-pdos/noria
When viewed as a DSL for set theory, views, CTEs, set-returning functions, et al are indeed proper first-class query abstractions.
When viewed through the lens of general purpose imperative or functional programming languages, it's easy to see how it can be seen as falling short.
I'll admit much of the tooling and driver APIs leave a lot to be desired.
Some tools do make good efforts though such as nested fragments in this driver.
https://github.com/porsager/postgres#building-queries
LINQ in EntityFramework (EF) supports querying JSON columns as objects [1].
unnest support is on the roadmap for EF core for PG [2], but already supported for Couchbase [3].
[1] https://learn.microsoft.com/en-ca/ef/core/what-is-new/ef-cor...
[2] https://github.com/npgsql/efcore.pg/issues/1525
[3] https://github.com/couchbaselabs/Linq2Couchbase/blob/master/...
LINQ in EntityFramework (EF) supports querying JSON columns as objects [1].
unnest support is on the roadmap for EF core for PG [2], but already supported for Couchbase [3].
[1] https://learn.microsoft.com/en-ca/ef/core/what-is-new/ef-cor...
[2] https://github.com/npgsql/efcore.pg/issues/1525
[3] https://github.com/couchbaselabs/Linq2Couchbase/blob/master/...