web/book/src/project/target.md
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
prql target:sql.mssql
from employees
sort age
take 10
Supported dialects support all PRQL language features where possible, are tested on every commit, and we'll endeavor to fix bugs.
sql.clickhousesql.duckdbsql.generic
{{footnote: while there's no "generic" DB to test sql.generic against, we still count it as supported.}}sql.glaredbsql.mysqlsql.postgressql.sqliteUnsupported 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.
sql.mssqlsql.ansisql.bigquerysql.snowflakesql.oracle — very early; currently only ensures identifiers are quoted to
accommodate Oracle's case-folding rules. Most other language features fall
back to generic SQL and may not execute correctly against Oracle.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
and sql.duckdb in the --target option of the prqlc compile command. In
this case, sql.duckdb takes precedence and the SQL output is based on the
DuckDB dialect.
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:
prql version:"0.13.12"
from employees
This has two roles, one of which is implemented:
The version of the compiler currently in use can be called using the special
function std.prql.version in PRQL.
[{version = prql.version}]