Skip to content

Database Compatibility

How General SQL Parser .NET handles dialect differences across the 15 supported database systems.

Supported vendors

The prebuilt NuGet ships with all 15 dialects:

Family Vendors EDbVendor constants
Traditional RDBMS Oracle, SQL Server, MySQL, PostgreSQL, DB2, Sybase, Informix dbvoracle, dbvmssql, dbvmysql, dbvpostgresql, dbvdb2, dbvsybase, dbvinformix
Cloud data warehouses Redshift, Snowflake dbvredshift, dbvsnowflake
Big data Hive, Impala dbvhive, dbvimpala
Specialised Teradata, Netezza, Greenplum dbvteradata, dbvnetezza, dbvgreenplum
OLAP MDX dbvmdx

Microsoft Access uses the dbvaccess alias of dbvmssql because the two dialects share grammar.

Per-vendor accuracy

Each dialect has its own lexer and parser, generated from a vendor-specific .l/.y grammar. There is no shared "core SQL" with dialect overlays. This means:

  • Vendor-specific keywords (CONNECT BY, TOP, QUALIFY, LATERAL) parse with the same accuracy as ANSI features.
  • A parse error tells you whether the SQL is valid for the target dialect, not "valid SQL in the abstract".
  • Reserved-word lists differ per vendor, so an identifier that's reserved in Oracle but not in PostgreSQL is handled correctly when you use the matching vendor.

The per-vendor SQL Syntax Support pages link to coverage reports generated by running the parser's regression suite against thousands of real-world SQL fixtures.

Vendor families with shared ancestry

Some dialects share ancestry. When you switch between them, expect mostly-identical behaviour with vendor-specific differences in reserved-word sets and dialect extensions:

  • PostgreSQL family: PostgreSQL, Greenplum, Redshift. Greenplum adds DISTRIBUTED BY and partitioning extensions; Redshift adds DISTKEY, SORTKEY, SUPER columns and a different reserved-word set.
  • T-SQL family: SQL Server (MSSQL), Sybase ASE. ASE has a few syntactic quirks ((...) around CREATE PROC parameters, different raiserror syntax).
  • Hive family: Hive, Impala. Impala adds NOT LIKE/RLIKE/REGEXP; Hive supports CTEs in more positions.

When fixing a bug in one of these, we routinely check the siblings. If you find that a query parses in PostgreSQL but not Greenplum (or vice versa), it's worth opening an issue — the gap is usually a small grammar omission.

Identifier case rules

Each vendor folds and compares identifiers differently:

Vendor Unquoted identifiers Quoted identifiers
Oracle, DB2, Snowflake Fold to UPPER, case-insensitive Preserve case, case-sensitive
PostgreSQL, Hive, Teradata Fold to lower, case-insensitive Preserve case, case-sensitive
SQL Server Preserve case, collation-based Preserve case, collation-based
MySQL Depends on lower_case_table_names Preserve case, case-insensitive

The defaults match each vendor's standard behaviour.

Vendor-specific statement classes

Statements that only exist in one dialect have their own subclass under the matching stmt/<vendor>/ namespace:

  • Oracle: TPlsqlCreatePackage, TPlsqlCreateProcedure, TPlsqlCreateFunction, TSqlplusCmdStatement (for SQL*Plus commands like WHENEVER SQLERROR).
  • SQL Server: TMssqlBlock, TMssqlCreateProcedure, TMssqlExecute, TMssqlDeclareCursor, TMssqlAlterSecurityPolicy.
  • Teradata: TTeradataBTEQCmd (for BTEQ utility commands).
  • Snowflake: vendor-specific DDL (streams, stages, etc.).

What we don't do

  • No SQL translation between vendors. GSP parses; it does not automatically rewrite Oracle SQL as PostgreSQL SQL. The AST gives you the raw material to write a translator yourself, but no shipped product does this end-to-end.
  • No semantic validation against a live schema. The parser doesn't know whether employees.salary exists; it only knows that employees.salary is a syntactically valid column reference. For schema-aware analysis, see the dataFlowAnalyzer demo, which can take a metadata.json schema description as input.
  • No execution. The parser is read-only against your database. It does not connect, query, or modify anything.

See also