Currently it is only possible to retrieve warnings by checking the warning count and retrieve the warnings afterwards via SHOW WARNINGS after processing all result sets.

This method has several flaws, since it is not always possible to retrieve all warnings, e.g. when calling a stored procedure or when executing multi (semicolon separated) statements:

MariaDB [test]> drop table if exists t1; drop table if exists t2;

Query OK, 0 rows affected, 1 warning (0.018 sec)

Query OK, 0 rows affected, 1 warning (0.005 sec)

MariaDB [test]> show warnings;

+-------+------+-------------------------+

| Level | Code | Message                 |

+-------+------+-------------------------+

| Note  | 1051 | Unknown table 'test.t2' |

+-------+------+-------------------------+

A better approach would be to send warnings (if requested by client) via session tracking as part of the OK packet for each statement.

If the client is interested in warnings, it will set the capability CLIENT_SESSION_TRACK and the new variable @@session_track_warnings:
Possible Values {-1,0,n}:

• 0 don't send warnings (default)
• n specifies the maximum number of warnings

If one or more warnings occur, the server sends back warnings within the OK packet:

  <int1>    Session change type: 0xFF  SESSION_TRACK_WARNINGS

  <intlenc> Total length

  while packet has remaining data

    <int2>    error/warning number

    <strlenc> warning text

If *@@session_track_warnings@@ was set to 0 (OFF), warnings can be still retrieved via SHOW WARNINGS.