fix detection of multi-statements in ComPrepare

[jycor]

Currently, preparing multi-statements is not supported; so we can't prepare a query like select ?; select ?;.
However, the check for this condition just looked for any characters after the first ;, which meant that queries like select ?; \n would incorrectly throw an error.

This was made apparent using the Prisma ORM, which runs the query:

SELECT TABLE_NAME AS view_name, VIEW_DEFINITION AS view_sql
FROM INFORMATION_SCHEMA.VIEWS
WHERE TABLE_SCHEMA = ?;

The above query ends in a newline character.

The fix is to use SplitStatementToPieces(), which trims these white space characters, and check if there's exactly one piece; this was taken from the vitessio repo: https://github.com/vitessio/vitess/blob/main/go/mysql/conn.go#L1204

fixes dolthub/dolt#8157

[fulghum]

Change make sense; just a couple things I wanted to understand before approving.

[fulghum]

Looks like this is just a debugging/testing change? Should this test fail when multiple statements are included? Seems like it's still passing though?

[jycor]

Oops yeah, this was a debugging change.
This test should fail when there are multiple statments; it doesn't currently because the check is in handleNextCommand.

I'll move this test case to a different testing suite, and check for an error.

[fulghum]

Maybe rename to TestComStmtPrepareWithTrailingNewline or something? That's a little more descriptive of what you're testing here (there aren't actually multiple statements, right?) and more consistent with the naming of the existing test TestComStmtPrepare.

Speaking of multiple statements... do we have a test in here that tests the "prepare fails for multiple statements" case? It seems like that would be useful if we don't have it.

[fulghum]

Looks like we will still execute this code even if we send back the error response packet about not being able to prepare multiple statements? Should we return from this function earlier to avoid letting this execute in that case?

[fulghum]

Looks good! 🚢