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.
The default one (with MacOS 10.13) is too old with most Homebrew
packages (including MySQL) available in the source code form only
without prebuilt bottles.
Remove the legacy 'special' distribution, because it was unscientific
and hard to explain.
Pareto and Zipfian distributions provide more clearly defined
alternatives.
