Supported SQL: Difference between revisions

From MemCP
Jump to navigation Jump to search
No edit summary
(Refresh MemCP documentation: accuracy, operational guidance, performance profile and maintained API reference)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Statements ==
<!-- Copyright (C) 2026 Carl-Philip Haensch -->
The following SQL statements are supported:


* SELECT FROM GROUP BY HAVING ORDER BY LIMIT OFFSET
<!-- SPDX-License-Identifier: GPL-3.0-or-later -->
* UPDATE SET WHERE
* DELETE FROM WHERE
* INSERT INTO VALUES ON DUPLICATE KEY UPDATE / INSERT ... ON CONFLICT (PostgreSQL)
* INSERT IGNORE
* CREATE TABLE
* ALTER TABLE
* CREATE DATABASE
* CREATE USER
* ALTER USER
* SHOW DATABASES
* SHOW TABLES
* SHOW TABLE STATUS
* SHOW VARIABLES
* SET NAMES (no function)
* DROP DATABASE
* DROP TABLE
* SET SESSION
* LOCK TABLES (no function)
* UNLOCK TABLES (no function)


<span id="supported-sql"></span>
= Supported SQL =
<blockquote>Verified against development commit <code>c42e19eba</code> on 27 August 2026. MemCP is Beta and does not claim complete MySQL or PostgreSQL compatibility. Unsupported shapes should fail explicitly; test a required workload before migration.
</blockquote>
This page is a capability map for application evaluation. MemCP accepts a broad MySQL-oriented dialect through its MySQL protocol and HTTP endpoint, plus PostgreSQL-oriented syntax through a separate HTTP endpoint. Both compile into the same logical planner and storage runtime, but accepted surface syntax and returned metadata can differ by frontend.
Support is defined by tested semantics, not merely by whether the parser accepts a statement. Compatibility-only clauses may intentionally be no-ops, and uncommon combinations can remain unsupported even when their individual operators are available. Use this overview to select candidates, then verify every required query, constraint, transaction, prepared statement, and client behavior against the deployed release.
<span id="query-language"></span>
== Query language ==
* <code>SELECT</code>, aliases, <code>WHERE</code>, <code>DISTINCT</code>, <code>GROUP BY</code>, <code>HAVING</code>, <code>ORDER BY</code>, <code>LIMIT</code>, and <code>OFFSET</code>;
* <code>INNER</code>, <code>LEFT</code>, <code>RIGHT</code>, and <code>CROSS JOIN</code>;
* <code>UNION</code> and <code>UNION ALL</code>, including ordered/limited set results;
* derived tables and logical SQL views;
* scalar, <code>EXISTS</code>, <code>NOT EXISTS</code>, <code>IN</code>, and <code>NOT IN</code> subqueries, including many correlated and grouped forms;
* aggregates <code>COUNT</code>, <code>SUM</code>, <code>AVG</code>, <code>MIN</code>, <code>MAX</code>, and <code>GROUP_CONCAT</code>;
* window functions including <code>ROW_NUMBER</code>, <code>RANK</code>, <code>DENSE_RANK</code>, <code>LEAD</code>, <code>LAG</code>, <code>FIRST_VALUE</code>, and <code>LAST_VALUE</code> with partition/order clauses.
<span id="data-modification-and-schema"></span>
== Data modification and schema ==
* single- and multi-row <code>INSERT</code>, <code>INSERT IGNORE</code>, <code>INSERT … SELECT</code>, and MySQL or PostgreSQL upsert syntax;
* <code>UPDATE</code> and <code>DELETE</code>, including qualified and supported multi-table forms;
* <code>CREATE</code>, <code>ALTER</code>, <code>RENAME</code>, <code>TRUNCATE</code>, and <code>DROP</code> for databases and tables;
* <code>CREATE VIEW</code>, indexes, primary/unique keys, foreign keys, defaults, <code>AUTO_INCREMENT</code>, computed expressions, types, collations, and per-table ENGINE;
* persistent BEFORE/AFTER triggers for INSERT, UPDATE, and DELETE.
Foreign keys are enforced for the tested RESTRICT, CASCADE, and SET NULL paths. Some compatibility DDL is intentionally accepted as a no-op; for example, a client accepting <code>ADD FULLTEXT</code> does not imply a MySQL-compatible full-text index implementation.
<span id="transactions-security-and-metadata"></span>
== Transactions, security, and metadata ==
* <code>BEGIN</code>, <code>COMMIT</code>, and <code>ROLLBACK</code>;
* users, passwords, grants, revokes, and database access policies;
* <code>SHOW DATABASES</code>, tables, columns, indexes, create-table metadata, variables, engines, processlist, and selected <code>INFORMATION_SCHEMA</code> relations;
* prepared statements over the MySQL protocol;
* <code>KILL QUERY</code> and <code>KILL CONNECTION</code>.
See [[Transactions_and_Isolation|Transactions and Isolation]] and [[Security_and_Authentication|Security and Authentication]] for the operational contract.
<span id="expressions"></span>
== Expressions ==
== Expressions ==
The following functions are supported:
* CASE WHEN THEN ELSE END
* DATABASE
* PASSWORD (hashes a password for user authentication)
* FLOOR
* CEIL
* CEILING
* ROUND
* UPPER
* LOWER
* CAST AS UNSIGNED
* CAST AS CHAR CHARACTER SET utf8
* CONCAT
* COALESCE
* UNIX_TIMESTAMP
* LIKE
* ILIKE


== Aggregates ==
MemCP implements SQL NULL/three-valued logic, CASE, COALESCE/NULLIF/IFNULL, arithmetic and bitwise operators, comparisons, BETWEEN, IN lists, LIKE/ILIKE, REGEXP/RLIKE, MATCH…AGAINST compatibility, casts, string functions, mathematical functions, hashes, date/time functions, intervals, and timezone conversion.
The following aggregates are available:
 
The exact parser and function catalog changes more often than this overview. Use the generated API reference and the SQL test taxonomy for detailed coverage.


* COUNT
<span id="json"></span>
* SUM
== JSON ==
* AVG
* MIN
* MAX


== Modifiers ==
MemCP stores declared <code>JSON</code>/<code>JSONB</code> values in a native tagged BSON representation. The MySQL dialect implements JSON validation, type inspection, path extraction, constructors, aggregates, mutation functions, containment/search operations, <code>JSON_TABLE</code>, and the <code>-></code>/<code>->></code> operators. The PostgreSQL dialect provides its corresponding <code>json</code>/<code>jsonb</code> operators, constructors, aggregates, path functions, and set-returning expansion forms. Deterministic path expressions can be materialized and indexed through the ordinary computed-column/index machinery. See [[JSON]] for the detailed compatibility contract and deviations.


* COLLATE
<span id="planner-inspection"></span>
== Planner inspection ==


== JSON ==
<pre>EXPLAIN SELECT ...;
JSON support is documented separately in the [[JSON|MemCP MySQL- and Postgres-compatible JSON SQL]]
EXPLAIN IR SELECT ...;
EXPLAIN REORDER SELECT ...;
EXPLAIN PHYSICAL SELECT ...;
EXPLAIN COMPILE SELECT ...;</pre>
See [[Query Planner and Physical Lowering]].
 
<span id="known-limitations"></span>
== Known limitations ==
 
MemCP is not a byte-for-byte MySQL server implementation. Metadata details, administrative commands, uncommon syntax, advanced locking modes, XA, stored procedures, and untested SQL-standard edge cases may be absent. Consult the [https://github.com/launix-de/memcp/issues current issue tracker] and add a must-pass and must-fail test for every application-critical construct.

Latest revision as of 12:14, 28 August 2026


Supported SQL

Verified against development commit c42e19eba on 27 August 2026. MemCP is Beta and does not claim complete MySQL or PostgreSQL compatibility. Unsupported shapes should fail explicitly; test a required workload before migration.

This page is a capability map for application evaluation. MemCP accepts a broad MySQL-oriented dialect through its MySQL protocol and HTTP endpoint, plus PostgreSQL-oriented syntax through a separate HTTP endpoint. Both compile into the same logical planner and storage runtime, but accepted surface syntax and returned metadata can differ by frontend.

Support is defined by tested semantics, not merely by whether the parser accepts a statement. Compatibility-only clauses may intentionally be no-ops, and uncommon combinations can remain unsupported even when their individual operators are available. Use this overview to select candidates, then verify every required query, constraint, transaction, prepared statement, and client behavior against the deployed release.

Query language

  • SELECT, aliases, WHERE, DISTINCT, GROUP BY, HAVING, ORDER BY, LIMIT, and OFFSET;
  • INNER, LEFT, RIGHT, and CROSS JOIN;
  • UNION and UNION ALL, including ordered/limited set results;
  • derived tables and logical SQL views;
  • scalar, EXISTS, NOT EXISTS, IN, and NOT IN subqueries, including many correlated and grouped forms;
  • aggregates COUNT, SUM, AVG, MIN, MAX, and GROUP_CONCAT;
  • window functions including ROW_NUMBER, RANK, DENSE_RANK, LEAD, LAG, FIRST_VALUE, and LAST_VALUE with partition/order clauses.

Data modification and schema

  • single- and multi-row INSERT, INSERT IGNORE, INSERT … SELECT, and MySQL or PostgreSQL upsert syntax;
  • UPDATE and DELETE, including qualified and supported multi-table forms;
  • CREATE, ALTER, RENAME, TRUNCATE, and DROP for databases and tables;
  • CREATE VIEW, indexes, primary/unique keys, foreign keys, defaults, AUTO_INCREMENT, computed expressions, types, collations, and per-table ENGINE;
  • persistent BEFORE/AFTER triggers for INSERT, UPDATE, and DELETE.

Foreign keys are enforced for the tested RESTRICT, CASCADE, and SET NULL paths. Some compatibility DDL is intentionally accepted as a no-op; for example, a client accepting ADD FULLTEXT does not imply a MySQL-compatible full-text index implementation.

Transactions, security, and metadata

  • BEGIN, COMMIT, and ROLLBACK;
  • users, passwords, grants, revokes, and database access policies;
  • SHOW DATABASES, tables, columns, indexes, create-table metadata, variables, engines, processlist, and selected INFORMATION_SCHEMA relations;
  • prepared statements over the MySQL protocol;
  • KILL QUERY and KILL CONNECTION.

See Transactions and Isolation and Security and Authentication for the operational contract.

Expressions

MemCP implements SQL NULL/three-valued logic, CASE, COALESCE/NULLIF/IFNULL, arithmetic and bitwise operators, comparisons, BETWEEN, IN lists, LIKE/ILIKE, REGEXP/RLIKE, MATCH…AGAINST compatibility, casts, string functions, mathematical functions, hashes, date/time functions, intervals, and timezone conversion.

The exact parser and function catalog changes more often than this overview. Use the generated API reference and the SQL test taxonomy for detailed coverage.

JSON

MemCP stores declared JSON/JSONB values in a native tagged BSON representation. The MySQL dialect implements JSON validation, type inspection, path extraction, constructors, aggregates, mutation functions, containment/search operations, JSON_TABLE, and the ->/->> operators. The PostgreSQL dialect provides its corresponding json/jsonb operators, constructors, aggregates, path functions, and set-returning expansion forms. Deterministic path expressions can be materialized and indexed through the ordinary computed-column/index machinery. See JSON for the detailed compatibility contract and deviations.

Planner inspection

EXPLAIN SELECT ...;
EXPLAIN IR SELECT ...;
EXPLAIN REORDER SELECT ...;
EXPLAIN PHYSICAL SELECT ...;
EXPLAIN COMPILE SELECT ...;

See Query Planner and Physical Lowering.

Known limitations

MemCP is not a byte-for-byte MySQL server implementation. Metadata details, administrative commands, uncommon syntax, advanced locking modes, XA, stored procedures, and untested SQL-standard edge cases may be absent. Consult the current issue tracker and add a must-pass and must-fail test for every application-critical construct.