implementing PREPARE, EXECUTE, and DEALLOCATE
#1448
Conversation
| @@ -334,6 +351,73 @@ func (e *Engine) analyzeQuery(ctx *sql.Context, query string, parsed sql.Node, b | |||
| return nil, err | |||
| } | |||
|
|
|||
| switch n := parsed.(type) { | |||
There was a problem hiding this comment.
I haven't thought through this fully yet... so I might be missing something... but I'm wondering if there is another way to execute these statements that is more similar to how we execute other statements. It seems inconsistent that these statements are "executed" directly inside engine.go. I'm wondering if that creates other edge cases.
I see that they need to access the engine to call some functions, but I'm wondering if you had the PreparedStatementCache type I mentioned in a previous comment that could be set in these types, if that would decouple them.
There was a problem hiding this comment.
I do agree it's a little strange to have these in the engine.go file, but I couldn't think of another place to put it.
I'm not quite sure what happens when you prepare a prepare statement either, but I'm assuming not great things.
There was a problem hiding this comment.
Good edge case with preparing a prepare statement! It looks like MySQL's grammar doesn't allow this, so it's always a syntax error. Would definitely be a good test case to cover.
There was a problem hiding this comment.
Now that you have PreparedDataCache... it seems like you're closer to being able to pull this out of engine.go... if you could set the PreparedDataCache instance on these plan nodes, then they could run their logic to set/delete in the cache as part of their rowIter func. Seems like we would need another analyzer rule to catch these nodes and run the Analyzer calls to PrepareQuery and AnalyzedPrepared though.
@max-hoffman – what do you think? any better ideas for us here?
There was a problem hiding this comment.
i think the answer depends on whether PREPARE and DEALLOCATE are exempted from the transactional lifecycle. for example, if you start a transaction with an already prepared query, unbind a prepared statement, and then rollback the unbind, does MySQL restore the prepared query? or did the unbind not respect transaction boundaries? the reverse -- prepare a statement, and then rollback -- does the session still see the cached plan?
| @@ -55,6 +55,65 @@ type TemporaryUser struct { | |||
| Password string | |||
| } | |||
|
|
|||
| // PreparedDataCache manages all the prepared data for every session for every query for an engine | |||
| type PreparedDataCache struct { | |||
There was a problem hiding this comment.
This is beautiful! It encapsulates this logic cleanly, shrinks the locking granularity, and makes this code a lot easier to read. Nice work! 👏
fx for: dolthub/dolt#4452