👍 it might be nice to refactor fn table() to call this function now to avoid some duplication.

👍 this is a good idea

I suggest we simply panic in the sqllogic runner in these cases so the location of the error is easier to see

LGTM

👍 I like this basic approach (special case the sql and route it to the test runner implementation).

One thing that might be worth doing is to actually try and parse the input into sql, to detect INSERT statements though I think string manipulation is fine too or we could do this later

    // Handle any test only special case statements
    let sql = sql.into();
    match DFParser::parse_sql(&sql) {
        Ok(Statement(Insert)) => {
        //debug!("Parsed statement: {:#?}", stmt);

        }
        Err(_) => {
            // ignore anything else, including errors -- they will be handled by the sql context below
        }
    };

Yes, more generic way, will fix in next PR.

👍

This is very clever

Rather than changing the batches in the existing memtable, what would you think about creating a new memtable with the same name with the new values (rather than modifying the original one)

I think you might be able to avoid changes to SessionContext and MemTable entirely.

Something like this (untested)

// fetch existing batches
let mut existing_batches = ctx.table(table_name.as_str()).collect();
// append new batch
exsiting_batches.extend(insert_batches)

// Replace table provider provider
let new_provider = MemTable::try_new(batches[0].schema(), vec![batches]);
ctx.register_table(table_name, new_provider)

Yes, I have thought about the way you mentioned, (also need to delete original memtable).

-- But for performance reasons, I choose the current way: modifying the original one.

If you think the changes to add interior mutability to MemTable don't make sense, I can change it in the following ticket! (I don't have a strong bias for both ways)

I think keeping MemTable as simple as possible is likely the best approach -- so for that reason I prefer to remove the interior mutability.

I can give it a shot if you agree -- I think the performance of copying record batches (for reasonably small data such as what is in the test) will be ok

Ok, agree! Thanks @alamb . I'll refactor it later.

Thank you very much!