Dialect classification happens automatically during Phase 1 (Discovery) of the conversion pipeline. You don't need to tell 3XCode what dialect a file is written in. The agent reads the SQL, classifies it into a SQLDialect value, and a separate deterministic layer then narrows that down to a specific source platform (Snowflake, Oracle, SQL Server, and so on). Every gotcha, mapping table, and validation rule the pipeline applies is selected based on this classification, so getting familiar with which dialect your source SQL falls into helps you understand the conversion notes and TODOs you'll see in the output.
Supported Dialects
| Dialect | Maps To | Conversion Approach |
|---|---|---|
tsql (T-SQL) | SQL Server | Full rewrite. Cursors become window functions, `DATEDIFF` argument order is corrected, and dynamic SQL / transactions are flagged for manual review. |
plsql (PL/SQL) | Oracle | Full rewrite. Procedures, packages, and cursor-heavy loops are restructured into PySpark functions; `MERGE` and dynamic SQL are flagged for manual review. |
plpgsql (PL/pgSQL) | PostgreSQL, Amazon Redshift | Full rewrite. Postgres-derived syntax (including Redshift extensions) is converted to native PySpark; NULL-ordering and window-frame differences get explicit TODOs. |
mysql (MySQL) | MySQL | Full rewrite. Stored procedures and string/date-function differences are mapped to their PySpark equivalents. |
ansi (ANSI SQL) | Snowflake, BigQuery, Teradata (generic catch-all) | Full rewrite using standard ANSI SQL semantics. Used whenever the source syntax doesn't match a more specific dialect above; the separate platform-detection layer still identifies the actual vendor for markers and TODOs. |
spark_sql (Spark SQL) | Databricks SQL, Hive | Same engine as the PySpark target: conversion is about idiom and readability, not correctness. Output focuses on converting SQL statements into equivalent DataFrame API calls rather than fixing semantic gaps. |
How Dialect Detection Works
Detection happens in two distinct layers during Discovery, and it's worth understanding why there are two:
Layer 1: LLM Dialect Classification
Claude reads the file and assigns one of the seven SQLDialect values. A field validator then normalizes dozens of LLM spellings into the canonical form: for example, 'Transact-SQL', 'Azure SQL', and 'Synapse' all normalize to tsql; 'Postgres' and 'Redshift' normalize to plpgsql; 'Hive', 'HiveQL', and 'Databricks SQL' normalize to spark_sql.
Layer 2: Deterministic Platform Detection
A separate, regex-only pass (no LLM call) scores the SQL text against 133 syntax markers across 10 platforms (Databricks, Snowflake, PostgreSQL, MySQL, SQL Server, Oracle, Redshift, BigQuery, Teradata, and Hive) and returns the winning platform with a confidence label and the exact markers that fired.
Platform detection is fully explainable (nothing black-box), and it never blocks the pipeline: if it fails for any reason, discovery simply skips it and conversion proceeds using the dialect classification alone. You can see both the dialect and the detected platform for a file without running a full conversion by using analyze:
# Discovery + Planning only, no conversion, shows detected dialect/platform 3xcode pyspark analyze your_file.sql
Dialect vs. Platform
Dialect = syntax family
One of seven SQLDialect values (tsql, plsql, plpgsql, mysql, ansi, spark_sql, unknown). This is what drives which gotchas, mapping tables, and knowledge-base sections get selectively injected into the conversion prompt.
Platform = specific vendor
One of 10 platforms identified by regex markers (e.g. Snowflake vs. BigQuery vs. Teradata all fall under the ansi dialect family, but are different platforms). Platform is annotated in output file headers alongside detection confidence.
Unrecognized SQL
unknown dialect: still attempted
If the LLM's classification doesn't match any recognized spelling, the validator coerces it to unknown rather than failing outright. Conversion still runs. The pipeline just can't selectively inject dialect-specific gotchas, so expect more generic TODOs in the output.
Graceful degradation by design
This mirrors how Discovery handles malformed inventories generally: objects that validate get salvaged and kept, rather than the whole file being discarded on a single classification miss.