Skip to content

RonSQL#

NOTE: RonSQL as described in this chapter is not yet fully implemented.

RonSQL is a subset of MySQL, currently supporting only aggregation queries. A query that is accepted by RonSQL should always produce the same result as MySQL, but hopefully execute faster. This document only details the supported subset of MySQL. For the meaning of functions, operators and other keywords, refer to the MySQL documentation.

Usage#

The command-line tool ronsql_cli can be used to execute RonSQL queries, but is only suitable for testing. Note that this tool has a latency overhead of more than 1s due to having to connect to the NDB cluster at every startup. By comparison, mysql quickly connect to mysqld, which manages an already open connection to the NDB cluster.

In production, the recommended way to execute RonSQL queries is to use the REST API.

Functionality#

  • SELECT is the only statement supported. A select expression can only be

    • A column name. The column name must appear among the columns in the GROUP BY clause, even though MySQL does not require this.

    • An aggregate function AVG, COUNT, MAX, MIN, STD/STDDEV/STDEV_POP, SUM or VAR_POP/VARIANCE, of an arithmetic expression. Since only aggregate queries are supported, at least one select expression must be an aggregate function. The arithmetic expression can only contain

      • Parentheses

      • Column names

      • Integer literals

      • Operators +, -, *, /, DIV and %.

    • COUNT(*).

    • One of the above, aliased using AS.

  • FROM is required and can only refer to one table. No joins or subqueries.

  • WHERE is supported. The condition is restricted to the following:

    • Parentheses

    • Column names

    • Integer literals

    • String literals

    • Operators OR, ||, XOR, AND, &&, NOT, =, >=, >, <=, <, !=, <>, IS NULL, IS NOT NULL, |, &, <<, >>, +, -, *, /, DIV, %, ^ and !.

    • Functions DATE_ADD, DATE_SUB and EXTRACT with constant-only arguments, e.g. DATE_ADD(’2024-05-07’, INTERVAL ’75’ MICROSECOND).

  • GROUP BY: Supported, but only for column names. Expressions and aliases are not supported.

  • ORDER BY, ASC, DESC: Supported, but only for column names and aliases. Expressions are not supported.

Supported data types#

  • Signed and unsigned numeric types are supported, including TINYINT, SMALLINT, MEDIUMINT, INT/INTEGER, BIGINT, FLOAT/REAL, DOUBLE/DOUBLE PRECISION and DECIMAL.

  • VARCHAR is supported, except in aggregate function arguments.

  • DATE, DATETIME and TIMESTAMP are not supported. However, constant expressions in DATE_ADD and DATE_SUB are still supported.

Syntax elements#

  • Column names are case sensitive.

  • Single-quoted strings are supported in the WHERE condition, but not as the alias after AS. Therefore, aliases cannot contain characters with code points higher than U+FFFF. Character set introducer and COLLATE clause are not supported.

  • Column names, table names and aliases can be unquoted or use backtick quotes. However, unquoted identifiers may not coincide with a MySQL keyword, even if such unquoted identifier is allowed by MySQL, and even if the keyword is not implemented by RonSQL.

  • Aliases after AS are limited to 64 bytes rather than 256. Similar to MySQL, the length limits for other identifiers are 64 bytes. However, providing a longer identifier produces an error rather than truncation. Even without an alias, the limit on the output column name is 64 bytes and will not be truncated. For very complex expressions, this means that a shorter alias provided with AS is required. Note that the MySQL documentation incorrectlyd claims that the identifier length limits are a certain number of characters, while the actual limit is in bytes. When using UTF-8, the number of characters is less than the number of bytes whenever an identifier contains a character with a code point greater than U+007f.

  • Double quotes are not supported, neither for identifiers nor strings. This makes the ANSI_QUOTES SQL mode irrelevant.

Encoding#

  • RonSQL supports and requires UTF-8 encoding for both input SQL and query output.

  • NUL characters are not allowed anywhere, but can be represented in strings by means of escape sequence.

  • No Unicode normalization will be performed by the server.