Issue #401 Support of MariaDB prepared statement metadata caching.

[lawrinn]

This is the part of the implementation of the #401

The fix sends metadata caching extended capability flag if server set it too. If this extended MariaDB capability flag is set, it expects that there can be no metadata in the Ok packet and uses for query result the metadata from prepare.
The patch contains the test for metadata consistency and covers among others the case when metadata is different after prepare and after execute("SELECT ?").

Since the fix relies on the fix in mysql_common that is not yet merged, the patch currently changes Cargo.toml to use mysql_common from my fork.

The PR is submitted on behalf of my employer, MariaDB Corporation plc. We are planning further support and implement MariaDB specific features.

[lawrinn]

Looks like I've overlooked and the patch in current form causes test failures ironically with MariaDB. I am looking into it.

[blackbeam]

It is now fails on MySql and it seems that the server always sends the same metadata even though the parameter type was updated. Don't you know if there is a relevant bug report somewhere in the MySql bug tracker?

mysql> PREPARE stmt1 FROM 'SELECT ?';
Query OK, 0 rows affected (0,01 sec)
Statement prepared

mysql> SET @a = 12;
Query OK, 0 rows affected (0,00 sec)

mysql> EXECUTE stmt1 USING @a;
+------+
| ?    |
+------+
|   12 |
+------+
1 row in set (0,00 sec)

mysql> SET @b = 42;
Query OK, 0 rows affected (0,00 sec)

mysql> EXECUTE stmt1 USING @b;
+------+
| ?    |
+------+
|   42 |
+------+
1 row in set (0,00 sec)

mysql> SET @c = 'foo';
Query OK, 0 rows affected (0,00 sec)

mysql> EXECUTE stmt1 USING @c;
+------+
| ?    |
+------+
|    0 | <-- THIS IS WRONG
+------+
1 row in set, 1 warning (0,01 sec)

[blackbeam]

This seems not to be a bug from the devs perspective, so I'll just ignore the test for non-mariadb server
(see https://bugs.mysql.com/bug.php?id=111921 starting from "[2 Aug 2023 7:31] Roy Lyseng").

[lawrinn]

First of all - thank you for cooperation and for the prompt correcting of my PR's. Not much of my code left, but yours is definitely cleaner and more important - correct, while my was still buggy :)
That bug report is about different issue it seems, but the Roy's comment is relevant. In your example it seems that the server doesn't change the type of parameter after first execute, and it determines the type of the result column. Then 'foo' is simply treated as a number and the result is 0.
If their documentation really says that the query has to be re-prepared in case of change of the parameter type, than it's not a bug and that check can be omitted for mysql server.
What about conn::test::my_conn::should_change_user on Windows? for me locally it failed with or without my changes and it fails in Azure pipelines. I can always have something wrongly configured for your tests, so is it ok that it fails? Otherwise it's the only remaining issue if I'm not missing anything.

[blackbeam]

What about conn::test::my_conn::should_change_user on Windows?

I'm not really sure about the reason of this error. I tried to reproduce it on an actual windows PC with the same mysql server version and couldn't. I'll ignore it for now.

[lawrinn]

Thank you!
As for the failing test - I've verified it does not fail for me with MySQL server as well, and failures with MariaDB server are because secures_auth is on and ed25519 is not loaded by default. Technically, the test could do set GLOBAL secure_auth=OFF (and then ON) and INSTALL SONAME 'auth_ed25519', or could skip those checks if they are not possible with current server settings.
Also, on the 2nd thought that MySQL bug report appears to be for the same problem - parameter type changes, server does not re-prepare the query and treats parameters as if they were of the old type. MariaDB server re-prepare in such case.