Use SET syntax as specified in the MySQL documentation

[beautifulentropy]

Description

PR #1099 was able save on round-trip-time by SETting multiple variables in a single transaction. However, the syntax used is out of alignment with both the MySQL and MariaDB docs. Specifically there are missing spaces around the equals (=) sign and after each comma (,).

Syntax output by go-sql-driver/mysql:

SET variable=expr[,variable=expr]...

Syntax as specified in the MySQL 8.0 documentation.

SET variable = expr [, variable = expr] ...

Syntax as specified in the MariaDB documentation:

SET variable_assignment [, variable_assignment] ...

variable_assignment:
      user_var_name = expr
    | [GLOBAL | SESSION] system_var_name = expr
    | [@@global. | @@session. | @@]system_var_name = expr

The SET syntax output by go-sql-driver/mysql is accepted by recent versions of MariaDB in our testing. Unfortunately we've encountered significant issues when these statements are parsed by ProxySQL, a tool we use for efficient routing of queries to our various MariaDB servers.

Checklist

• Code compiles correctly
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary
• Added myself / the copyright holder to the AUTHORS file

[pgporada]

An example of how go-sql-driver/mysql v1.6 and v1.7 sending the extended SET syntax to ProxySQL is mangled by regex capturing in that software.

2214 Connect  bad-key-revoker@host on database using TCP/IP
2214 Query    SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED,long_query_time
2214 Query    SET sql_mode='STRICT_ALL_TABLES'

Notice how there is a trailing ,long_query_time in SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED,long_query_time.

With the fix from @beautifulentropy this is the correct output we now see going through go-sql-driver/mysql => ProxySQL => MariaDB.

7323 Connect  bad-key-revoker@host on database using TCP/IP
7323 Query    SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
7323 Query    SET long_query_time=2880
7323 Query    SET sql_mode='STRICT_ALL_TABLES'
7323 Query    SET long_query_time = 2880, max_statement_time = 3420, sql_mode = STRICT_ALL_TABLES, tx_isolation = 'READ-UNCOMMITTED'

[methane]

thanks

[dolmen]

@beautifulentropy So this is a workaround for a bug in ProxySQL, isn't it?

If yes, could you link to the ticket you opened on the ProxySQL project?

[beautifulentropy]

@beautifulentropy So this is a workaround for a bug in ProxySQL, isn't it?

If yes, could you link to the ticket you opened on the ProxySQL project?

I don't believe it's fair to characterize this as a "workaround for a bug in ProxySQL". In the issue above I describe how this package passes variables using a SET syntax which isn't described in the official MySQL or MariaDB documentation. The PR simply corrects the package to pass the variables using the syntax as specified by the the maintainers of both projects. Similarly, I don't feel that it's appropriate to open an issue with ProxySQL to support a syntax which isn't documented by either project.

[dolmen]

@beautifulentropy Here is the reference documentation:

• https://dev.mysql.com/doc/refman/8.1/en/set-variable.html
• https://dev.mysql.com/doc/refman/8.1/en/user-variables.html

That documentation doesn't mention anywhere that spaces are mandatory around = or ,. Could you point me to the doc I missed?

[pgporada]

You linked to the correct docs just as the PR description linked to prior versions of mariadb/mysql docs. While the docs do not explicitly go on to explain why spaces are mandatory around = and ,, the example code block at the top of each of the linked doc page is quite clear. The code block shows spaces surrounding the = and a space surrounding the ,.

SET variable = expr [, variable = expr] ...

[beautifulentropy]

You linked to the correct docs just as the PR description linked to prior versions of mariadb/mysql docs. While the docs do not explicitly go on to explain that spaces are mandatory around = and ,, the example code block at the top of each of the linked doc page is quite clear. The code block shows spaces surrounding the = and a space surrounding the ,.

SET variable = expr [, variable = expr] ...

Thanks @pgporada 👍🏻. I'd also like to highlight that the link to the SET syntax outlined in the MariaDB documentation, which was provided in the PR description, aligns with the syntax found in the MySQL documentation links you've presented.

[dolmen]

Spaces in examples are for readability for humans.

Here we are discussing about machine-to-machine interactions.

Spaces are NOT mandatory around commas.

[evanelias]

The root cause here was a ProxySQL bug, see sysown/proxysql#4268 (comment). It appears to have been fixed sometime last year.

fwiw, to the best of my knowledge, the MySQL manual and MariaDB manual both use spaces in the grammar strictly for human readability. The server's lexer treats spaces as entirely optional in situations where the division between tokens is unambiguous. For a couple extreme examples, these horribly-formatted queries are actually completely legal:

SELECT'foo'AS'lol'FROM(SELECT'ok')x;

select*from`information_schema`.`tables`where`engine`='innodb';

Ambiguous cases do require spaces, for example you must use limit 1 and never limit1, because the latter could be an identifier name.

I've been using MySQL continuously since 2003, and to the best of my recollection it has always worked this way. The manual doesn't explicitly state this one way or another, to be fair. But it does provide detailed documentation on the rare edge cases in which whitespace is meaningful. Off the top of my head, I can think of only two of those cases:

• Spaces cannot occur between function names and the opening paren of the function arg list, unless the non-default IGNORE_SPACE sql_mode is enabled; see manual https://dev.mysql.com/doc/refman/8.0/en/function-resolution.html

• When using the SQL standard -- style comment syntax, whitespace must be used after -- to disambiguate between a comment and an expression subtracting a negative number; see manual https://dev.mysql.com/doc/refman/8.0/en/ansi-diff-comments.html

Since there's no corresponding long discussion in the manual around SET args, I would interpret that as meaning whitespace is optional there. In any case that's how the server actually behaves in that situation too.

Anyway, sorry for rambling on a year-old PR. Personally for my two cents, I don't think this PR should be reverted anytime soon. ProxySQL is widely used (it's great software) and it will be a long while until every ProxySQL user upgrades to a new enough version that fixes this bug. Paying a measly two extra bytes per session variable is a low cost to help with compatibility here.

That said, for future situations like this, I would strongly urge opening an issue with ProxySQL. Regardless of how one interprets the MySQL manual, this situation is technically a parser differential, and (in general) parser differentials between proxies and backends are like catnip to clever attackers looking for crazy ways to build SQL injection attacks or find information leaks. I doubt this one is exploitable, but who knows, and there's no harm in reporting it.

[beautifulentropy]

@evanelias as much as you might feel awkward for "rambling on a year-old PR". Thanks for taking the time to write this, it was super informative.