PRQL allows specifying a target dialect at the top of the query, which allows PRQL to compile to a database-specific SQL flavor.
prql target:sql.postgres from employees sort age take 10
SELECT * FROM employees ORDER BY age LIMIT 10
prql target:sql.mssql from employees sort age take 10
SELECT TOP (10) * FROM employees ORDER BY age
Supported dialects support all PRQL language features where possible, are tested on every commit, and we’ll endeavor to fix bugs.
Unsupported dialects have implementations in the compiler, but are tested minimally or not at all, and may have gaps for some features.
We’re open to contributions to improve our coverage of these, and to adding additional dialects.
The compile target of a query is defined in the query’s header or as an argument to the compiler. option. The argument to the compiler takes precedence.
For example, the following shell example specifies
sql.generic in the query
sql.duckdb in the
--target option of the
prqlc compile command. In
sql.duckdb takes precedence and the SQL output is based on the
echo 'prql target:sql.generic from foo' | prqlc compile --target sql.duckdb
To use the target described in the query, a special target
sql.any can be
specified in the compiler option.
echo 'prql target:sql.generic from foo' | prqlc compile --target sql.any
PRQL allows specifying a version of the language in the PRQL header, like:
This has two roles, one of which is implemented:
- The compiler will raise an error if the compiler is older than the query version. This prevents confusing errors when queries use newer features of the language but the compiler hasn’t yet been upgraded.
- The compiler will compile for the major version of the query. This allows the
language to evolve without breaking existing queries, or forcing multiple
installations of the compiler. This isn’t yet implemented, but is a gating
feature for PRQL 1.0.
1: while there’s no “generic” DB to test
sql.generic against, we still count it as supported.