GoSQLX SQL Feature Compatibility Matrix#

Overview#

This matrix documents the comprehensive SQL feature support in GoSQLX across different SQL dialects and standards. The testing was conducted using the comprehensive integration test suite with 700+ test cases covering real-world SQL patterns.

Real-world dialect audit (October 2026)#

The real-world corpus contains 2,813 production-style statements: SQL written by hand to imitate what ORMs, migration tools and applications send, not SQL collected from production systems. Every statement passes split → dialect-aware parse → format → reparse → format idempotency, plus a check for dropped SQL words. testdata/realworld/known_failures.txt lists no failures. These results describe this corpus; they do not establish complete dialect coverage or database execution equivalence. Some routine and utility statements retain their text rather than receiving a complete semantic AST.

The table totals 2,813 statements and was checked with scripts/dialect-audit at commit fda9a5ef. Reproduce one dialect's row from the repository root (replace <d> with a dialect string such as mysql); the last line of output reads, for example:

dialect=mysql total=405 passed=405 failed=0 stages=map[ok:405]

The command is:

go run ./scripts/dialect-audit -dialect <d> testdata/realworld/<d>/*.sql

The same command audits your own SQL files. To reproduce the ratchet and every per-dialect summary at once:

go test ./pkg/gosqlx -run '^TestRealWorldCorpus$' -count=1
for dir in testdata/realworld/*/; do
  go run ./scripts/dialect-audit -dialect "$(basename "$dir")" "$dir"*.sql
done

TestRealWorldCorpus is a ratchet against known_failures.txt: a statement that fails and is not listed fails the test, and so does a listed statement that now passes, so the list can only shrink. Regenerate it with go test ./pkg/gosqlx -run TestRealWorldCorpus -update-known-failures. BenchmarkRealWorldParse and BenchmarkRealWorldParseFormat measure the corpus.

SQL Server batch boundaries also have whole-script round-trip tests: the AST retains each GO as a BatchSeparator, including its optional repeat count, and both library and CLI rendering keep it on a separate line. The splitter removes client directives when returning individual SQL statements, so the statement-by-statement corpus totals above do not count GO directives.

Feature Highlights#

Snowflake and ClickHouse#

• ✅ Snowflake: 87/87 QA corpus pass (MATCH_RECOGNIZE, QUALIFY, VARIANT paths, time-travel, LATERAL FLATTEN, stage/stream/task/pipe stubs)
• ✅ ClickHouse: 83/83 QA corpus pass: ARRAY JOIN, scalar CTEs, CREATE MATERIALIZED VIEW, numeric SAMPLE ... OFFSET, LIMIT offset, count
• See Snowflake and ClickHouse below for per-dialect details

SQLite, Security Scanner and Error Codes#

• ✅ SQLite PRAGMA: Fully parsed - bare (PRAGMA x), arg (PRAGMA x(n)), and assignment (PRAGMA x=v) forms; PragmaStatement AST node
• ✅ WITHOUT ROWID: CREATE TABLE ... WITHOUT ROWID; reserved keywords now valid as DDL column names
• ✅ Tautology Detection: ScanSQL() detects 1=1, 'a'='a', col=col, OR TRUE → CRITICAL severity (PatternTautology)
• ✅ UNION Detection Split: PatternUnionInjection (CRITICAL, system tables + NULL padding) / PatternUnionGeneric (HIGH) - eliminates false-positive CRITICAL on legitimate queries
• ✅ E1009: ErrCodeUnterminatedBlockComment for unterminated /* ... */ block comments
• ✅ Dialect Fixes: MySQL backtick + SQL Server bracket reserved-word identifiers now parsed correctly
• ✅ Parser Fixes: KEY/INDEX in qualified names, NATURAL JOIN type, OVER window_name (bare name per SQL:2003 §7.11)

Dialect Engine and MySQL Syntax#

• ✅ Dialect Mode Engine: First-class dialect support with ParseWithDialect() - thread dialect through tokenizer and parser
• ✅ MySQL Syntax Support:
  • LIMIT offset, count - MySQL-style LIMIT 10, 20
  • ON DUPLICATE KEY UPDATE - MySQL upsert syntax
  • SHOW statements - SHOW TABLES, SHOW DATABASES, SHOW CREATE TABLE
  • DESCRIBE/EXPLAIN - Table description commands
  • REPLACE INTO - MySQL insert-or-replace
  • UPDATE/DELETE with LIMIT - MySQL extension
  • GROUP_CONCAT - With ORDER BY and SEPARATOR clause
  • MATCH AGAINST - Full-text search expressions
  • REGEXP/RLIKE - Regular expression operators
  • INTERVAL number unit - MySQL-style INTERVAL 30 DAY
• ✅ Query Transform API: Programmatic SQL rewriting via pkg/transform/
• ✅ Comment Preservation: Comments survive parse-format round-trips
• ✅ AST-to-SQL Serialization: SQL() methods on all AST nodes
• ✅ Dollar-Quoted Strings: PostgreSQL $$body$$ and $tag$body$tag$
• ✅ Error Recovery: Multi-error parsing with ParseWithRecovery()
• ✅ ~50% Faster Parsing: Token type overhaul with O(1) integer comparison
• ✅ Snowflake Dialect: Keyword detection and weighted dialect scoring

Schema-Qualified Names and PostgreSQL Enhancements#

• ✅ Schema-Qualified Names: Full support for schema.table, db.schema.table in all DML/DDL statements
• ✅ PostgreSQL Enhancements:
  • Type Casting - :: operator for PostgreSQL-style casts (SELECT 1::int)
  • UPSERT - INSERT ... ON CONFLICT DO UPDATE/NOTHING
  • Positional Parameters - $1, $2 style parameter placeholders (PostgreSQL); ? placeholders for MySQL/MariaDB/SQLite (dialect-gated); :1/:name bind variables for Oracle (dialect-gated)
  • JSONB Operators - Additional @? and @@ operators
  • Regex Operators - ~, ~*, !~, !~* for pattern matching
• ✅ ARRAY Constructors: ARRAY[1, 2, 3] expressions with subscript/slice operations
• ✅ WITHIN GROUP - Ordered-set aggregate functions
• ✅ INTERVAL Expressions - INTERVAL '1 day' temporal literals, plus the ANSI qualifier form INTERVAL '1' DAY / INTERVAL '1-2' YEAR TO MONTH
• ✅ FOR UPDATE/SHARE - Row-level locking clauses
• ✅ Multi-row INSERT - INSERT INTO t VALUES (1), (2), (3) batch inserts

PostgreSQL Extensions and SQL Standards#

• ✅ PostgreSQL Extensions:
  • LATERAL JOIN - Correlated subqueries and table functions in FROM/JOIN clauses; select the PostgreSQL dialect for table functions
  • Table Function Aliases - Column alias lists and WITH ORDINALITY on FROM/JOIN table functions: unnest(arr) AS g(elem), generate_series(1, 3) WITH ORDINALITY AS s(n, idx). WITH ORDINALITY is PostgreSQL-only.
  • Composite Field Access - (get_item(payload)).name, (payload).*, quoted fields and chained field/subscript access such as (payload).items[1].name and (items)[1].name. Any keyword, reserved ones included, is accepted as a field name, e.g. (payload).order. Field access parses for PostgreSQL, BigQuery, the generic dialect and the default (no dialect) parser; MySQL, MariaDB, SQL Server, SQLite, Oracle, Snowflake, ClickHouse and Redshift reject it with E4001.
  • JSON/JSONB Operators - Complete operator set (->, ->>, #>, #>>, @>, <@, ?, ?|, ?&, #-)
  • DISTINCT ON - PostgreSQL-specific row selection
  • FILTER Clause - Conditional aggregation (SQL:2003)
  • Aggregate ORDER BY - Ordering within aggregate functions
  • RETURNING Clause - Return modified rows from INSERT/UPDATE/DELETE
• ✅ SQL Standards:
  • FETCH FIRST n ROWS - Standard row limiting (SQL-99 F861)
  • FETCH WITH TIES - Include tied rows (SQL-99 F862)
  • OFFSET-FETCH - Standard pagination
  • TRUNCATE TABLE - SQL:2008 table truncation
  • Materialized CTE Hints - CTE optimization

Core SQL Features#

• ✅ MERGE Statements (SQL:2003 F312)
• ✅ GROUPING SETS, ROLLUP, CUBE (SQL-99 T431)
• ✅ Materialized Views (CREATE, DROP, REFRESH)
• ✅ Table Partitioning (RANGE, LIST, HASH)
• ✅ NULLS FIRST/LAST (SQL-99 F851)
• ✅ Advanced Operators (BETWEEN, IN, LIKE, IS NULL)
• ✅ Comprehensive Subqueries (Scalar, Table, Correlated, EXISTS)
• ✅ Window Functions - Complete SQL-99 support (ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, etc.)
• ✅ SQL Injection Detection (pkg/sql/security package)

Legend#

• ✅ Full Support: Complete parsing and AST generation with validation
• ⚠️ Partial Support: Basic syntax recognition, limited semantic validation
• ❌ Not Supported: Feature not recognized or causes parsing errors
• 🔧 Syntax Only: Recognizes syntax but no semantic validation

Core SQL Features Support Matrix#

Data Manipulation Language (DML)#

Data Definition Language (DDL)#

JOIN Operations#

Subqueries#

Aggregate Functions#

Advanced SQL Features#

Common Table Expressions (CTEs)#

Window Functions#

Set Operations#

Parenthesized operands such as (SELECT ... ORDER BY a LIMIT 5) UNION ALL (SELECT ...) and SELECT ... EXCEPT (SELECT ... UNION SELECT ...) keep their parentheses when rendered. An ORDER BY/LIMIT written after a parenthesized query is accepted when it can be represented without changing meaning (for example (SELECT 1) ORDER BY 1); a second ORDER BY/LIMIT level over a parenthesized query that already has one, such as (SELECT a FROM t ORDER BY a LIMIT 10) ORDER BY b, returns E4001 (unsupported feature).

Grouping Operations (SQL-99 T431)#

ORDER BY Extensions (SQL-99 F851)#

Expression Operators#

Dialect-Specific Features#

Note: This section documents dialect-specific features where "Support Level" refers to the native database's support, while "GoSQLX Parser" and "Test Coverage" indicate GoSQLX implementation status. Many features listed have keyword recognition only (🔧 Syntax) without full parsing logic.

PostgreSQL-Specific Features#

MySQL-Specific Features#

|| operator in MySQL and MariaDB#

In MySQL and MariaDB || is a synonym for OR unless the server runs with the PIPES_AS_CONCAT SQL mode. GoSQLX follows the server default:

• With the mysql or mariadb dialect, a = 1 || b parses as (a = 1) OR b, with OR precedence (looser than AND, NOT, comparisons and arithmetic). The AST is the same as for the OR keyword (BinaryExpression{Operator: "OR"}), so linter rules, the security scanner and other analysis see an OR. The node also sets PipesOr: true, and SQL(), the formatter, the CLI and LSP formatting write || back, so formatting never changes the meaning for a server that runs with PIPES_AS_CONCAT.
• To mirror PIPES_AS_CONCAT, pass parser.WithPipesAsConcat() (or gosqlx.WithPipesAsConcat() with gosqlx.ParseTree); || is then string concatenation. The CLI, LSP and linter configuration do not expose this option yet, so with --dialect mysql they analyse || as OR (for example OR-based lint rules may report a concatenation).
• Precedence in the opt-in mode differs from MySQL: MySQL gives || under PIPES_AS_CONCAT a precedence between ^ and the unary operators, tighter than *, /, + and -. GoSQLX places concatenation just below + and -, so a + b || c parses as (a + b) || c, while MySQL reads a + (b || c). Parenthesise mixed arithmetic and concatenation.
• Every other dialect (PostgreSQL, SQL Server, Oracle, SQLite, Snowflake, ClickHouse, and no dialect) always parses || as concatenation.
• Transpiling from any of those dialects to MySQL or MariaDB rewrites a || b to CONCAT(a, b). Transpiling from MySQL or MariaDB to any of them writes a || OR as OR; between MySQL and MariaDB it stays ||.

// MySQL default: || is logical OR
p := parser.NewParser(parser.WithDialect("mysql"))

// MySQL with PIPES_AS_CONCAT: || is concatenation
p2 := parser.NewParser(parser.WithDialect("mysql"), parser.WithPipesAsConcat())

tree, err := gosqlx.ParseTree(ctx, sql,
    gosqlx.WithDialect("mysql"), gosqlx.WithPipesAsConcat())

Before v1.16.0 (#781), || was concatenation in every dialect, including MySQL and MariaDB.

MariaDB-Specific Features#

MariaDB inherits all MySQL features (SHOW, DESCRIBE, REPLACE INTO, ON DUPLICATE KEY UPDATE, GROUP_CONCAT, MATCH/AGAINST, REGEXP/RLIKE, backtick identifiers, etc.) and adds the following extensions:

SQL Server-Specific Features#

Oracle-Specific Features#

SQLite-Specific Features#

Statement syntax#

These forms are available in v1.17.0. Each example was parsed with gosqlx.ParseWithDialect and formatted with gosqlx.FormatWithDialect in the named dialect.

Related grammar checks: outside SQL Server, a utility statement (SET, USE, GRANT, COPY, CALL, ...) followed on the next line by another statement without ; is an error (E2002); transaction statements are checked against each dialect's grammar (BEGIN banana is rejected); an unbalanced SQL Server BEGIN ... END block is an error.

SQL Standards Compliance#

SQL-92 (Entry Level)#

SQL-99 (Core Features)#

SQL-2003 (XML Features)#

SQL-2006 (Enhancement)#

SQL-2008 (Enhancements)#

SQL-2011 (Temporal Data)#

SQL-2016 (JSON Support)#

PostgreSQL Extension Summary#

GoSQLX provides comprehensive PostgreSQL-specific feature support, making it one of the most PostgreSQL-compatible SQL parsers available.

Complete PostgreSQL Feature Set#

JSON/JSONB Operator Examples#

-- Extract field as JSON (->)
SELECT data->'user' FROM events;

-- Extract field as text (->>)
SELECT data->>'email' FROM users;

-- Extract nested path as JSON (#>)
SELECT data#>'{user,address,city}' FROM profiles;

-- Extract nested path as text (#>>)
SELECT data#>>'{user,name}' FROM profiles;

-- Contains (@>)
SELECT * FROM products WHERE attributes @> '{"color": "red"}';

-- Contained by (<@)
SELECT * FROM users WHERE tags <@ '["admin", "user"]';

-- Key exists (?)
SELECT * FROM profiles WHERE data ? 'email';

-- Any key exists (?|)
SELECT * FROM users WHERE profile ?| array['phone', 'mobile'];

-- All keys exist (?&)
SELECT * FROM users WHERE profile ?& array['name', 'email'];

-- Delete path (#-)
SELECT data #- '{user,temp}' FROM cache;

LATERAL JOIN Examples#

-- Correlated subquery in FROM clause
SELECT u.name, recent.order_date
FROM users u,
LATERAL (
    SELECT order_date FROM orders
    WHERE user_id = u.id
    ORDER BY order_date DESC
    LIMIT 3
) recent;

-- LEFT LATERAL JOIN
SELECT u.name, stats.total
FROM users u
LEFT JOIN LATERAL (
    SELECT SUM(amount) as total
    FROM transactions
    WHERE user_id = u.id
) stats ON true;

DISTINCT ON Examples#

-- Get first row per department
SELECT DISTINCT ON (dept_id) dept_id, name, salary
FROM employees
ORDER BY dept_id, salary DESC;

-- Latest status per user
SELECT DISTINCT ON (user_id) user_id, status, updated_at
FROM user_status_log
ORDER BY user_id, updated_at DESC;

FILTER Clause Examples#

-- Multi-condition aggregation
SELECT
    dept_id,
    COUNT(*) FILTER (WHERE status = 'active') AS active_count,
    COUNT(*) FILTER (WHERE status = 'inactive') AS inactive_count,
    SUM(salary) FILTER (WHERE bonus_eligible = true) AS bonus_pool
FROM employees
GROUP BY dept_id;

RETURNING Clause Examples#

-- INSERT with RETURNING
INSERT INTO users (name, email)
VALUES ('John Doe', 'john@example.com')
RETURNING id, created_at;

-- UPDATE with RETURNING
UPDATE products
SET price = price * 1.1
WHERE category = 'Electronics'
RETURNING id, name, price;

-- DELETE with RETURNING
DELETE FROM sessions
WHERE expired_at < NOW()
RETURNING user_id, session_id;

Dialect Mode Engine#

GoSQLX provides a first-class dialect mode engine that threads the SQL dialect through the tokenizer and parser. This enables dialect-specific keyword recognition, syntax parsing, and validation.

Supported Dialects#

Usage#

// API
ast, err := parser.ParseWithDialect("SHOW TABLES", "mysql")
err = parser.ValidateWithDialect("DESCRIBE users", "mysql")

// CLI
gosqlx validate --dialect mysql "SHOW TABLES"
gosqlx format --dialect mysql query.sql

Known Gaps by Dialect#

PostgreSQL (default, best supported)#

• PL/pgSQL procedural blocks not parsed
• Some advanced array operations limited
• Full-text search tsvector/tsquery syntax-only recognition

MySQL#

• Stored procedures / functions not parsed
• HANDLER statements not supported
• XA transactions not supported
• CREATE EVENT not supported

SQL Server (T-SQL)#

• PIVOT/UNPIVOT parsed (since v1.14.0)
• CROSS/OUTER APPLY keywords reserved but no parsing logic
• TRY/CATCH blocks not supported
• OPENROWSET / OPENQUERY not supported

Oracle#

• CONNECT BY / START WITH / PRIOR parsed (PRIOR is a prefix operator, since v1.16.0)
• PL/SQL blocks not supported
• DECODE recognized as generic function only
• Pipelined table functions not supported

SQLite#

• ATTACH/DETACH not parsed (keywords reserved)
• VACUUM not supported
• Virtual tables (FTS5, rtree) not supported

Snowflake#

• 87/87 QA corpus pass (100%)
• MATCH_RECOGNIZE (SQL:2016 R010), @stage references, SAMPLE/TABLESAMPLE, QUALIFY
• VARIANT colon-path expressions (expr:field.sub[0])
• Time-travel: AT/BEFORE/CHANGES
• MINUS as EXCEPT synonym, LATERAL FLATTEN, named arguments (name => expr)
• TRY_CAST, IGNORE NULLS / RESPECT NULLS
• LIKE ANY/ALL and ILIKE ANY/ALL
• CREATE STAGE/STREAM/TASK/PIPE stubs (parsed but not semantically validated)
• USE [WAREHOUSE|DATABASE|SCHEMA|ROLE], DESCRIBE with object-kind prefixes
• COPY INTO / PUT / GET / LIST / REMOVE stubs

MariaDB#

• Inherits all MySQL known gaps (stored procedures, HANDLER, XA transactions, CREATE EVENT)
• JSON_TABLE not supported
• Spider storage engine syntax not parsed
• ColumnStore-specific syntax not supported

ClickHouse#

• 83/83 QA corpus pass (100%). It closed the remaining QA gaps: ARRAY JOIN / LEFT ARRAY JOIN, scalar CTEs (WITH <expr> AS <name>), CREATE MATERIALIZED VIEW with ENGINE/TO, CREATE TABLE ... AS <source> ENGINE = ..., numeric SAMPLE arguments with OFFSET, and LIMIT offset, count
• PREWHERE clause for pre-filter optimization before primary key scan
• FINAL modifier on table references (forces MergeTree part merge)
• GLOBAL IN / GLOBAL NOT IN for distributed query execution
• ClickHouse data types: FixedString(N), LowCardinality(T), Nullable(T), Array(T), Map(K,V), DateTime64, IPv4, IPv6
• MergeTree engine family keywords: MERGETREE, REPLACINGMERGETREE, AGGREGATINGMERGETREE, SUMMINGMERGETREE, COLLAPSINGMERGETREE, VERSIONEDCOLLAPSINGMERGETREE
• Nested column types, parametric aggregates (quantile(0.95)(duration))
• Bare-bracket array literals [1,2,3], ORDER BY WITH FILL, CODEC(...)
• WITH TOTALS in GROUP BY, LIMIT BY clause, ANY/ALL JOIN strictness
• SETTINGS, TTL, INSERT FORMAT (JSONEachRow, CSV, etc.)
• table, partition, tables, databases as identifiers
• Table functions in FROM: numbers(N), remote(...), file(...), url(...), merge(...), s3(...), values(...), etc.
• 30+ ClickHouse-specific keywords: TTL, CODEC, FORMAT, SETTINGS, DISTRIBUTED, etc.

BigQuery#

• PIVOT / UNPIVOT (#854): aggregate aliases and multiple aggregates (PIVOT (SUM(s) AS total, COUNT(*) AS n FOR q IN ('Q1' AS q1, 'Q2' q2))), UNPIVOT INCLUDE NULLS / EXCLUDE NULLS, row-value aliases with or without AS (string or INT64), and multi-column UNPIVOT (UNPIVOT ((a, b) FOR k IN ((c1, c2) AS 'x', (c3, c4) AS 'y')))
• PIVOT IN values must be literals or names; constant expressions such as IN (1 + 1) or IN (DATE '2024-01-01') are not parsed
• QUALIFY, UNNEST in FROM and (struct).field access are capability-gated; BigQuery has no dedicated keyword set
• Quoted PIVOT aggregate aliases and UNPIVOT value-column names retain their source delimiters, including BigQuery backticks and Oracle double quotes

Oracle also accepts aggregate aliases, multiple aggregates, INCLUDE/EXCLUDE NULLS and multi-column UNPIVOT; Snowflake accepts INCLUDE/EXCLUDE NULLS. SQL Server keeps the single-aggregate form without aliases or a NULLS modifier. Oracle's tuple row-value aliases ((c1, c2) AS ('a', 'b')) are not parsed.

SQL Standards Compliance Summary#

Overall Compliance#

Feature Category Compliance#

Dialect-Specific Compliance#

Performance Characteristics by Feature#

High Performance Features (>1M ops/sec)#

• Basic SELECT statements
• Simple INSERT/UPDATE/DELETE
• Basic WHERE clauses
• Simple JOINs (2-3 tables)
• Standard aggregate functions
• Basic subqueries

Good Performance Features (100K-1M ops/sec)#

• Complex WHERE clauses
• Multi-table JOINs (4-6 tables)
• Window functions
• Simple CTEs
• Set operations (UNION, etc.)
• Complex subqueries

Moderate Performance Features (10K-100K ops/sec)#

• Recursive CTEs
• Very complex JOINs (7+ tables)
• Deeply nested subqueries
• Complex window functions with frames
• Large CASE expressions

Lower Performance Features (<10K ops/sec)#

• Extremely complex queries (1000+ tokens)
• Deeply nested expressions (10+ levels)
• Very large DDL statements
• Queries with 100+ columns

Edge Case Support#

Unicode and International Support#

Extreme Query Patterns#

Error Recovery#

Production Readiness Summary#

Ready for Production#

Core DML/DDL:

• Core SQL operations (SELECT, INSERT, UPDATE, DELETE, TRUNCATE)
• Standard joins and subqueries (all types including LATERAL)
• Window functions and CTEs (including recursive and materialized hints)
• MERGE statements (SQL:2003 F312)
• GROUPING SETS, ROLLUP, CUBE (SQL-99 T431)
• Materialized views
• Table partitioning

PostgreSQL Extensions (since v1.6.0):

• JSON/JSONB operators - All 10 operators (->, ->>, #>, #>>, @>, <@, ?, ?|, ?&, #-)
• LATERAL JOIN - Full support with LEFT/INNER/CROSS variants
• DISTINCT ON - PostgreSQL-specific row selection
• FILTER clause - Conditional aggregation
• Aggregate ORDER BY - Ordering within aggregate functions
• RETURNING clause - INSERT/UPDATE/DELETE RETURNING

Standards & Performance:

• FETCH FIRST/NEXT - SQL-99 F861/F862 standard pagination
• OFFSET-FETCH - Standard row limiting
• Multi-dialect basic syntax
• Unicode and international text
• High-performance scenarios (1.38M+ ops/sec, 1.5M peak)

Suitable with Considerations#

• Advanced dialect-specific features (keyword recognition only for: CROSS/OUTER APPLY, ATTACH/DETACH)
• Complex XML operations (syntax recognition only)
• Dialect-specific functions (DECODE, NVL, recognized as generic functions)
• Newest SQL standard features (SQL-2011+)
• Very large query processing

Development Needed#

• Full XML function support
• Row pattern recognition (MATCH_RECOGNIZE)
• Complete temporal table support
• Advanced array operations

Recommendations#

For Web Applications#

• ✅ Excellent support for typical web app queries
• ✅ High performance for user authentication, content management
• ✅ Multi-dialect compatibility for different backends
• ✅ PostgreSQL JSON/JSONB support for modern document storage
• ✅ RETURNING clause for efficient single-trip operations

For Analytics Platforms#

• ✅ Strong support for complex analytical queries
• ✅ Full CTE and window function support
• ✅ GROUPING SETS, ROLLUP, CUBE for OLAP operations
• ✅ FILTER clause for conditional aggregation
• ⚠️ Consider dialect-specific features for advanced analytics

For PostgreSQL Applications#

• ✅ Industry-leading PostgreSQL support with 95% core feature coverage
• ✅ Complete JSON/JSONB operator support (10 operators)
• ✅ LATERAL JOIN for advanced correlated subqueries
• ✅ DISTINCT ON for PostgreSQL-specific deduplication
• ✅ Aggregate ORDER BY for string aggregation
• ✅ Best-in-class PostgreSQL compatibility

For Database Tools#

• ✅ Comprehensive DDL support
• ✅ Excellent error handling and recovery
• ✅ Multi-dialect parsing capabilities
• ✅ SQL injection detection built-in

For Migration Tools#

• ✅ Strong cross-dialect compatibility
• ✅ Robust error handling
• ✅ PostgreSQL extension awareness
• ⚠️ Manual handling needed for dialect-specific features (PIVOT, CONNECT BY)

Total Test Cases: 800+
Coverage Percentage: 95%+
SQL-99 Compliance: ~85%
PostgreSQL Compliance: ~95% (core features), ~85% (extensions)
MySQL Compliance: ~95% (core features), ~85% (extensions)