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

hopefully you'll forgive my pedantry - "union all" is vertical concat - "union" without the "all" gives you the distinct list

One of the reasons why SQL is crap: there should be no distinction between the two in relational algebra. A set of {A, B, C, B, C} is the same as {A, B, C}.

Detecting duplicates has a cost you can't just hand-wave away. UNION ALL tells the engine not to worry about it and just output as it sees it, usually going faster. Depends on your data needs.

And not treating relationships as sets has costs of its own -- for example it breaks relational formula equivalences that could be used for query optimization.

For some definitions of same as.

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.

Transpiling to SQL doesn't mean all the underlying SQL features are being exposed to you.

Yes, that's what I meant by "not sure about the reverse".

Thanks, I missed that it transpiles to SQL.

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.

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.

No problem. (I didn't downvote.)