MySQL may return multiple result sets from a call to a stored
procedure (the CALL statement), or when multiple queries are specified
in a single client request. The application is supposed to process those
multiple result sets one by one with calls to `mysql_next_result()`, or
its prepared statements counterpart, `mysql_stmt_next_result()`.
Additionally, there is the `mysql_more_results()` call which allows the
application to check if more result sets are available and works for
both regular queries and prepared statements API.
One way to handle multiple results in sysbench would be consuming all
result sets silently in the MySQL driver, but that would make it
impossible for scripts to get access to individual result sets returned
by a stored procedure.
Now sysbench exposes those MySQL client API calls to the SQL API, so it
is up to the script authors to handle multiple result sets when either
stored procedures are used in a benchmark script, or multiple queries
are passed to `sql_connection:query()`:
- sql_connection:next_result()
- sql_connection:more_results()
- sql_statement:next_results()
Here is an example how multiple results can be handled in a benchmark
script:
```lua
local rs = con:query([[CALL p1("foo")]])
while rs ~= nil do
-- handle the result set
rs = con:next_result()
end
```
Here is a prepared statement example:
```lua
stmt = con:prepare("CALL p1(?)")
param = stmt:bind_create(sysbench.sql.type.CHAR, 10)
stmt:bind_param(param)
param:set("bar")
rs = stmt:execute()
while rs ~= nil do
rs = stmt:next_result()
end
```
Fixes GH-304.
If a Lua script defines the sysbench.hooks.sql_error_ignorable function,
sysbench calls it whenever an SQL error occurs and passes information
about connection, failed query, SQL error number, state and message as
arguments. If the function returns true, the error is ignored and the
entire event is restarted. Otherwise sysbench aborts scripts execution.
