4 ms·

I 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 g

I 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.

vkazanov 3y ago
Relational algebra is still great, it is the sql that made an unbelievable mess out of this beautiful idea.
aerzen 3y ago
People really like to associate relational algebra with SQL, probably because they learned them one alongside another. But SQL is really terrible relational language - it breaks a few core concepts in different places, like relations being unordered sets, that you can ORDER BY. This bubbles up as relations losing ordering after being wrapped into a subquery, which is really unexpected. PRQL has a data model very similar to the relational one. The only big difference is that relations are ordered - they are defined as arrays of tuples. So let's hope that PRQL gets to be known as "the relational language Mk II"
- cmrdporcupine 3y ago
  Seems like you'd have to break quite a few relational model concepts in order to retain compatibility with SQL, no? Ordered tuples like you say, but also duplicate tuples. And null values.
burcs 3y ago
Yeah, I have never liked that you choose what you are querying before you select the source. I think the formatting here is so much more intuitive.
snthpy 3y ago
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 https://github.com/ywelsch/duckdb-prql [2]: https://duckdb.org/docs/extensions/postgres_scanner.html https://duckdb.org/docs/extensions/postgres_scanner.html [3]: https://github.com/PRQL/prql/issues/1643 https://github.com/PRQL/prql/issues/1643 [4]: https://github.com/PRQL/pyprql https://github.com/PRQL/pyprql (Disclaimer: I'm a PRQL contributor.)
- stevage 3y ago
  By first party I assume they mean using psql and postgres's own tooling.
globular-toast 3y ago
Same. I first learnt SQL 20 years ago as a teenager and even back then I remember thinking how odd and, quite literally, backwards the language was. Back then I probably thought I just didn't understand enough to see why it had to be so. Now I know there is no reason. SQL has become more like a natural language. There's no arguing against it, you have to speak it even if it doesn't make sense. But it's not a natural language and we can do better.
- ako 3y ago
  It’s optimized for reading and use: the first time you see a query written by another developer, the interesting bit is what data it returns (the select part). Once you know that, you may be interested in the how, where does that data come from? Same for functions or methods, you first see the signature, input and output structures, before you see the implementation.
  - globular-toast 3y ago
    Good point, I didn't think of it like that and, oddly, I do often advocate for writing things "backwards" from highest level of abstraction to lowest. Maybe there is a good reason SQL has stuck around.

vkazanov 3y ago

Relational algebra is still great, it is the sql that made an unbelievable mess out of this beautiful idea.

aerzen 3y ago

People really like to associate relational algebra with SQL, probably because they learned them one alongside another. But SQL is really terrible relational language - it breaks a few core concepts in different places, like relations being unordered sets, that you can ORDER BY. This bubbles up as relations losing ordering after being wrapped into a subquery, which is really unexpected. PRQL has a data model very similar to the relational one. The only big difference is that relations are ordered - they are defined as arrays of tuples. So let's hope that PRQL gets to be known as "the relational language Mk II"

cmrdporcupine 3y ago
Seems like you'd have to break quite a few relational model concepts in order to retain compatibility with SQL, no? Ordered tuples like you say, but also duplicate tuples. And null values.

burcs 3y ago

Yeah, I have never liked that you choose what you are querying before you select the source. I think the formatting here is so much more intuitive.

snthpy 3y ago

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 https://github.com/ywelsch/duckdb-prql [2]: https://duckdb.org/docs/extensions/postgres_scanner.html https://duckdb.org/docs/extensions/postgres_scanner.html [3]: https://github.com/PRQL/prql/issues/1643 https://github.com/PRQL/prql/issues/1643 [4]: https://github.com/PRQL/pyprql https://github.com/PRQL/pyprql (Disclaimer: I'm a PRQL contributor.)

stevage 3y ago
By first party I assume they mean using psql and postgres's own tooling.

globular-toast 3y ago

Same. I first learnt SQL 20 years ago as a teenager and even back then I remember thinking how odd and, quite literally, backwards the language was. Back then I probably thought I just didn't understand enough to see why it had to be so. Now I know there is no reason. SQL has become more like a natural language. There's no arguing against it, you have to speak it even if it doesn't make sense. But it's not a natural language and we can do better.

ako 3y ago
It’s optimized for reading and use: the first time you see a query written by another developer, the interesting bit is what data it returns (the select part). Once you know that, you may be interested in the how, where does that data come from? Same for functions or methods, you first see the signature, input and output structures, before you see the implementation.
- globular-toast 3y ago
  Good point, I didn't think of it like that and, oddly, I do often advocate for writing things "backwards" from highest level of abstraction to lowest. Maybe there is a good reason SQL has stuck around.