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

11–20 of 166 posts

Re: Show HN: PRQL 0.2 – a better SQL

#11

Post by cogman10 »

roG0d wrote: post #8

I've been contributing to this project on a few little things due to my little knowledge level. But I felt like home with such a good company of people!. I not mature enough to fully appreciate the technical potential of the project, but the good ambient, the kindness and the growth potential is for sure worthwhile. I truly encourage everyone to contribute!

In particular, I think this is looking pretty good and I'd want to see even more complicated examples. For example, What do window functions end up looking like? [1]

What about crazy operations like calculating percentile_cont? [2]

Or just in general, how would "implementation specific" queries end up looking?

[1] https://www.postgresql.org/docs/current/tutorial-window.html

[2] https://docs.microsoft.com/en-us/sql/t-sql/functions/percent...

Re: Show HN: PRQL 0.2 – a better SQL

#12

Post by scottlamb »

ComputerGuru wrote: post #7

From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?

I assume it can't do anything SQL can't, because they write "It can be used with any database that uses SQL, since it transpiles to SQL." Not sure about the reverse.

I'm used to SQL syntax, but this has definite appeal. As a small example, I like that it starts with the "from" clause, so autocomplete is more viable.

Re: Show HN: PRQL 0.2 – a better SQL

#14

Post by aerzen »

ComputerGuru wrote: post #7

From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?

As said, currently PRQL transpiles to SQL, so all expressions in PRQL are can be expressed in SQL. But not all SQL expression can be translated back into PRQL - some intentionally and some are just not yet implemented (UNION - i.e. vertical concat).

But we also have plans for doing things that some SQL databases may not support, such as pivot (rows to columns).

Re: Show HN: PRQL 0.2 – a better SQL

#15

Post by paol »

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.

Re: Show HN: PRQL 0.2 – a better SQL

#16

Post by maximilianroos »

cogman10 wrote: post #11
roG0d wrote: post #8

I've been contributing to this project on a few little things due to my little knowledge level. But I felt like home with such a good company of people!. I not mature enough to fully appreciate the technical potential of the project, but the good ambient, the kindness and the growth potential is for sure worthwhile. I truly encourage everyone to contribute!

In particular, I think this is looking pretty good and I'd want to see even more complicated examples. For example, What do window functions end up looking like? [1] What about crazy operations like calculating percentile_cont? [2] Or just in general, how would "implementation specific" queries end up looking? [1] https://www.postgresql.org/docs/current/tutorial-window.html [2] https://docs.microsoft.com/en-us/sql/t-…

Great questions!

Window functions are here [1]. (We should add these to the homepage too)

Implementation specific queries can be handled by the Dialect parameter [2], though there's still lots of work to do to build that out.

[1]: https://prql-lang.org/book/transforms/window.html

[2]: https://prql-lang.org/book/queries/dialect_and_version.html

Re: Show HN: PRQL 0.2 – a better SQL

#18

Post by Beltiras »

ComputerGuru wrote: post #7

From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?

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 find it not capable of it.

Re: Show HN: PRQL 0.2 – a better SQL

#19

Post by ComputerGuru »

Beltiras wrote: post #18
ComputerGuru wrote: post #7

From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?

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.

Re: Show HN: PRQL 0.2 – a better SQL

#20

Post by ComputerGuru »

scottlamb wrote: post #12
ComputerGuru wrote: post #7

From a mathematical point-of-view are there any transforms/operations (note: not end results, but actual operations) that this can do that SQL can't or vice-versa?

I assume it can't do anything SQL can't, because they write "It can be used with any database that uses SQL, since it transpiles to SQL." Not sure about the reverse. I'm used to SQL syntax, but this has definite appeal. As a small example, I like that it starts with the "from" clause, so autocomplete is more viable.

Thanks, I missed that it transpiles to SQL.
Post reply on HN