Support multiple resultsets

[Jon Gjengset]

If a received query produces multiple result sets (e.g., because it contains multiple ;-separated queries), the MySQL binary protocol uses the MORE_RESULTS_EXISTS flag. Specifically, it sets the SERVER_MORE_RESULTS_EXISTS flag on the OK packet that follows each non-final result set. msql-srv does not yet support this feature.

The way to add support for this would likely be to add a continue method on RowWriter which finished up the current resultset with MORE_RESULTS_EXISTS set, and then returns another QueryResultWriter. There would also need to be something equivalent available for QueryResultWriter::completed and QueryResultWriter::error.

[Kenny Flegal]

Is this currently an open issue? The following test appears to cover this case:

#[test]
fn multi_result() {
    TestingShim::new(
        |_, w| {
            let cols = &[Column {
                table: String::new(),
                column: "a".to_owned(),
                coltype: myc::constants::ColumnType::MYSQL_TYPE_SHORT,
                colflags: myc::constants::ColumnFlags::empty(),
            }];
            let mut row = w.start(cols)?;
            row.write_col(1024i16)?;
            let w = row.finish_one()?;
            let mut row = w.start(cols)?;
            row.write_col(1025i16)?;
            row.finish()
        },
        |_| unreachable!(),
        |_, _, _| unreachable!(),
        |_, _| unreachable!(),
    ).test(|db| {
        let mut result = db.query("SELECT a FROM foo; SELECT a FROM foo").unwrap();
        assert!(result.more_results_exists());
        let row1: Vec<_> = result
            .by_ref()
            .filter_map(|row| row.unwrap().get::<i16, _>(0))
            .collect();
        assert_eq!(row1, vec![1024]);
        assert!(result.more_results_exists());
        let row2: Vec<_> = result
            .by_ref()
            .filter_map(|row| row.unwrap().get::<i16, _>(0))
            .collect();
        assert_eq!(row2, vec![1025]);
        assert!(!result.more_results_exists());
    })
}

The changes you mention in the ticket also seem to all be in place.

[Jon Gjengset]

Ah, yes, you're right, I fixed this in a7d4b0d, but forgot to close this issue. Thanks :)