Skip to content

Database Compatibility

How General SQL Parser handles dialect differences, and what the vendor you pass to the constructor actually changes.

Supported vendors

The two editions do not cover the same list, so which number you quote depends on which one you ship.

EDbVendor declares 45 constants. 43 of them parse ordinary SQL such as SELECT a FROM t, and none throw — an unsupported constant falls back to a working grammar rather than failing.

Coverage spans traditional RDBMS (Oracle, SQL Server, MySQL, PostgreSQL, DB2, Sybase, Informix, Firebird, OpenEdge, Dameng, EDB, GaussDB, OceanBase, Azure SQL), cloud warehouses (Snowflake, Redshift, BigQuery, Databricks, Athena, Vertica, Exasol, Netezza, Greenplum, Teradata), lakehouse and big-data engines (Hive, Impala, Spark SQL, Presto, Trino, Flink, Doris, StarRocks, ClickHouse, DuckDB, Couchbase), SQLite, and the OLAP/analytic languages MDX, DAX, PowerQuery and SOQL.

The per-vendor SQL Syntax Support pages are the authoritative list.

EDbVendor declares 23 constants, of which 15 are dedicated dialect grammars:

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

Unlike the Java edition, three constants are not usable for parsing:

dbvbigquery, dbvhana and dbvdax throw

They throw NotSupportedException from the TGSqlParser constructor. They exist for resolver / sqlenv vendor maps, not for parsing. dbvbigquery does work in the Java edition, so this is a genuine divergence between the editions rather than a documentation gap.

The remaining five (dbvaccess, dbvansi, dbvgeneric, dbvodbc, dbvfirebird) resolve to the T-SQL grammar — see below.

dbvaccess and friends are not aliases

Worth getting right, because this was previously documented the other way: dbvaccess is a distinct enum constant, not an alias of dbvmssql. In the Java edition their ordinals are 0 and 22; in .NET their values are 0 and 11. They are never the same object.

What is true is that dbvaccess routes to the T-SQL grammar. Tested against dialect-specific probes in both editions, it accepts SELECT TOP 10 and rejects MySQL backticks, PostgreSQL :: casts and Snowflake QUALIFY — identical to dbvmssql in every case. In .NET, dbvansi, dbvgeneric, dbvodbc and dbvfirebird behave the same way.

The practical consequence: if you pick dbvansi expecting strict standard SQL, or dbvfirebird expecting Firebird, you get T-SQL behaviour instead.

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 is reserved in Oracle but not in PostgreSQL is handled correctly when you use the matching vendor.

Vendor families with shared ancestry

Some dialects share ancestry. Switching between them gives mostly-identical behaviour, with 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 (parentheses around CREATE PROC parameters, different raiserror syntax).
  • Hive family: Hive, Impala. Impala adds NOT LIKE/RLIKE/REGEXP; Hive supports CTEs in more positions.

If a query parses under PostgreSQL but not Greenplum (or vice versa), that is worth reporting — the gap is usually a small grammar omission.

Identifier case rules

Each vendor folds and compares identifiers differently, and the defaults match each vendor's standard behaviour:

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

Vendor-specific statement classes

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

  • Oracle: TPlsqlCreatePackage, TPlsqlCreateProcedure, TPlsqlCreateFunction, TSqlplusCmdStatement (SQL*Plus commands such as WHENEVER SQLERROR)
  • SQL Server: TMssqlBlock, TMssqlCreateProcedure, TMssqlExecute, TMssqlDeclare
  • Teradata: TTeradataBTEQCmd (BTEQ utility commands)
  • Snowflake: vendor-specific DDL (streams, stages, and so on)

What the parser deliberately does not do

  • No SQL translation between vendors. GSP parses; it does not rewrite Oracle SQL as PostgreSQL SQL. The AST gives you the raw material to write a translator, but no shipped product does this end to end.
  • No semantic validation against a live schema. The parser does not know whether employees.salary exists; it knows that employees.salary is a syntactically valid column reference. For schema-aware analysis, the data-flow analyzer accepts a metadata description as input.
  • No execution. The parser is read-only with respect to your database. It does not connect, query, or modify anything.

See also