Portable scripts make sense. However, I think we should try to be consistent in direct execution and prepared execution as much as possible.

We need some simple explanation (to put it to the manual after the change) how we handle all these situations:

• Completely empty statements
• Empty statements consisting only of non-executable comments
• Statements consisting only of executible comments which are effectively empty because of the version

in all these execution types:

• Direct execution
• Prepared execution (PREPARE/EXECUTE and EXECUTE IMMEDIATE)

Just checked in 10.10:

For now, direct execution returns errors:

MariaDB [test]> /* */;

ERROR: No query specified

EXECUTE IMMEDIATE works without errors:

MariaDB [test]> execute immediate '/* */';

Query OK, 0 rows affected (0.001 sec)

PREPARE..EXECUTE works without errors:

MariaDB [test]> PREPARE stmt FROM '/* */';

Query OK, 0 rows affected (0.000 sec)

Statement prepared

MariaDB [test]> EXECUTE stmt;

Query OK, 0 rows affected (0.000 sec)

danblack, you know which commit allowed empty statements in prepared execution in the latest versions?

Found it: MDEV-16708 9370c6e83c148b4a5d4f08de7778e6a02da6adcb where the default condition changed to just a break.

Based on bar's evaluation, and the SQL standard, per MDEV-30772, we need to be consistent between prepared and non-prepared statements.

so:

• comments aren't allowed
• executable comments that evaluate to empty should be allowed.

So the test case is which should succeed without a return value:

MariaDB [test]> execute immediate '/*M!999999 should be no error */';

ERROR 1295 (HY000): This command is not supported in the prepared statement protocol yet

The current 10.3/4/5 behaviours are correct:

MariaDB [test]> execute immediate '';

ERROR 1065 (42000): Query was empty

MariaDB [test]> execute immediate '/* nothing */';

ERROR 1295 (HY000): This command is not supported in the prepared statement protocol yet