PRQL as a 100% replacement for SQL

[qharlie]

trafficstars

Opening this to track places we still need s-strings or other workarounds for full functionality.

[max-sixty]

Some issues on being able to extend s-strings:

• https://github.com/prql/prql/issues/919
• https://github.com/prql/prql/issues/376

I think s-strings are a great way of solving for a large number of corner cases, so I would vote to do what we can to allow those more pervasively (though I recognize there are genuine issues around variable resolution and query coherence)

[mklopets]

The main problem we're seeing with s-strings (even more so than e.g. variable resolution) is that you lose database-agnostic-ness (which is something we're trying our best to maintain).

[max-sixty]

Another current gap in s-strings is preventing them from being auto-formatted: https://github.com/prql/prql/issues/965. (Issue opened upstream, we can work around it if that doesn't yield anything)

[vanillajonathan]

PRQL is very far from a 100% replacement for SQL.

PRQL only a data query language (DQL), while SQL is a data query language (DQL), a data definition language (DDL), a data control language (DCL), and a data manipulation language (DML).

SQL have JSON, XML, constraints, triggers, collations, stored procedures, FFI, etc.

[max-sixty]

This issue is about being a replacement for the querying part of SQL @vanillajonathan