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

Show HN: PRQL 0.2 – a better SQL

github.com

Post reply on HN
Print view View original

21–30 of 166 posts

Re: Show HN: PRQL 0.2 – a better SQL

#21

Post by Beltiras »

ComputerGuru wrote: post #19
Beltiras wrote: post #18

Earlier quoted context omitted.

This can be transpiled into SQL which makes it then trivial that it can do everything SQL can do. SQL is Turing complete so it can do anything PRQL can do. EDIT: I'm sorry, I didn't realize that even if something transpiles from one language to another it does not guarantee that one language can generate all strings of another language. But taking a look at the abstractions PRQL offers I would be very surprised to fi…

The second part of your statement is fine, but the first part is just a complete fallacy. I can transpile a pure language exposing only `if`, `while`, and `for` with no standard library and no interop to C - that definitely does not make it "trivial" that it can do everything SQL can do.

I realized this after posting and edited the post. Thanks.

Re: Show HN: PRQL 0.2 – a better SQL

#23

Post by aerzen »

paol wrote: post #15

Here's one suggestion: SQL tediously requires specifying the equality condition on joins, when 90% of the time you just want to join on the fk defined between the tables. from a join b should implicitly join on the FK if no condition is given. It would require knowledge of the schema. I don't know if this is possible in PRQL, or if the transpilation to SQL has to be stateless.

Hello another contributor here!

Compilation does have to be stateless (for performance reasons), but we are planning to add some kind of schema definitions which could also specify foreign keys.

So joins without conditions would be possible, we'll look into it!

What do you think should happen if there are multiple foreign keys connecting the two tables? Should this also work for many-to-many relations with an intermediate table?

Re: Show HN: PRQL 0.2 – a better SQL

#24

Post by breakfastduck »

slotrans wrote: post #22

Hot takes: SQL is great, actually. This thing isn't better.

As much as I love SQL it can often be a pain and involve lots of nested subqueries to do 'simple' things. I like this way this abstracts it.

Would I use this instead of proper SQL in a data warehouse / large app? Maybe not.

Would I use it to manually query DBs when I need some ad hoc info? For sure.

Re: Show HN: PRQL 0.2 – a better SQL

#27

Post by aerzen »

davidw wrote: post #13

A good example might be a groupwise maximum. Those always tend to be a bit of a PITA in SQL if you're not writing them regularly. Be interesting to see what it transpiles to, as well.

If you only want maximum of one column, the PRQL is quite simple:

    from my_table
    group column_a (
      aggregate (max column_b)
    )
If you want the row with the maximum value it gets interesting:

    from my_table
    group column_a (
      sort [-column_b]
      take 1
    )
You can read more about group here: https://prql-lang.org/book/transforms/group.html

Re: Show HN: PRQL 0.2 – a better SQL

#29

Post by smallnamespace »

paol wrote: post #15

Here's one suggestion: SQL tediously requires specifying the equality condition on joins, when 90% of the time you just want to join on the fk defined between the tables. from a join b should implicitly join on the FK if no condition is given. It would require knowledge of the schema. I don't know if this is possible in PRQL, or if the transpilation to SQL has to be stateless.

If you're willing to sacrifice economics elsewhere, repeating the table's name in the id column is one workaround:

  from a
  join b on b.a_id = a.a_id
You can even use NATURAL JOIN if you can guarantee that the only fkey/pkey names will overlap between tables.

An unreasonable way to achieve that is to put the table name in every column. A more palatable way is to write some clever functions in your schema to scan the information table look for column name clashes (you essentially write a tiny "linter" inside your schema).

Post reply on HN