Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PRQL: Pipelined Relational Query Language

github.com

Post reply on HN
Print view View original

11–20 of 214 posts

Re: PRQL: Pipelined Relational Query Language

#11

Post by aerzen »

0cf8612b2e1e wrote: post #3

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.

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"

Re: PRQL: Pipelined Relational Query Language

#12

Post by qorrect »

athenot wrote: post #9
karmakaze wrote: post #8

How are joins handled? A relational db is largely about the relations, otherwise this is more of a document query language.

I had the same question. From the docs, it looks pretty elegant: from employees join side:left positions (employees.id==positions.employee_id) which translates to SELECT employees.*, positions.* FROM employees LEFT JOIN positions ON employees.id = positions.employee_id

I like it too. You can also alias them easily

    from e=employees
    join p=positions (e.id==p.employee_id)

Re: PRQL: Pipelined Relational Query Language

#13

Post by burcs »

0cf8612b2e1e wrote: post #3

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.

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.

Re: PRQL: Pipelined Relational Query Language

#14

Post by t8sr »

If the main complaint people have about SQL is that you can't swap SELECT, FROM and WHERE, then that's pretty good for a language designed in the 70s.

This, by contrast, looks like it has a bunch of random line noise for syntax. Why on earth should I like this:

`join side:left p=positions (p.id==employees.employee_id)`

better than this:

`LEFT JOIN positions AS p ON p.id = employees.employee_id` ?

Re: PRQL: Pipelined Relational Query Language

#15

Post by aerzen »

yevpats wrote: post #7

Looks interesting but I wonder if this abstraction doesn't leak and it doesn't just become a more limited version of vanilla python + vanilla SQL.

Vanilla python? Where do you get this impression?

The leak to SQL is trough s-strings, which are chunks of SQL that gets inlined into the resulting SQL. The long-term plan is to remove them completely, but they are needed as an escape-hatch for now.

Re: PRQL: Pipelined Relational Query Language

#16

Post by t8sr »

andrewl-hn wrote: post #6

For 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?

Re: PRQL: Pipelined Relational Query Language

#17

Post by yevpats »

aerzen wrote: post #15
yevpats wrote: post #7

Looks interesting but I wonder if this abstraction doesn't leak and it doesn't just become a more limited version of vanilla python + vanilla SQL.

Vanilla python? Where do you get this impression? The leak to SQL is trough s-strings, which are chunks of SQL that gets inlined into the resulting SQL. The long-term plan is to remove them completely, but they are needed as an escape-hatch for now.

I see that PRQL is compiled to SQL. How do you deal with different type of SQLs? i.e Snowflake/Postgres/Clickhouse? Isn't it a potentially impossible abstraction or at least there will be places where you will need to use the native support sql language (unless of course databases will adopt that in the first place which might be great)?

Re: PRQL: Pipelined Relational Query Language

#19

Post by spullara »

t8sr wrote: post #16
andrewl-hn wrote: post #6

For 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?

it seems like any SQL parser could let you put FROM first and solve a lot of the annoyances of SQL
Post reply on HN