fix: init Resultset in Result when handling ddl statement

[romberli]

this PR is to fix issue #577
as I only use client module of this repository and didn't use other modules like replication, server...etc, I'm not sure if this fix may impact the behavior of those modules, need some to review this.

[skoef]

After bisecting changes, I discovered that this will make my client using github.com/go-sql-driver/mysql panic. After I revert this, everything is fine again. Trace (from the client):

[mysql] 2021/06/22 15:19:26 packets.go:427: busy buffer
panic: runtime error: slice bounds out of range [2:1]

goroutine 49 [running]:
github.com/go-sql-driver/mysql.(*mysqlConn).handleOkPacket(0xc000078120, 0xc0001d1004, 0x1, 0xffc, 0x0, 0x0)
	/Users/skoef/go/pkg/mod/github.com/go-sql-driver/[email protected]/packets.go:620 +0x170
github.com/go-sql-driver/mysql.(*mysqlConn).readResultSetHeaderPacket(0xc000078120, 0x1224803, 0xc0000200f0, 0x23)
	/Users/skoef/go/pkg/mod/github.com/go-sql-driver/[email protected]/packets.go:542 +0x19c
github.com/go-sql-driver/mysql.(*mysqlConn).exec(0xc000078120, 0xc0000200f0, 0x23, 0x11f13c5, 0x12208c0)
	/Users/skoef/go/pkg/mod/github.com/go-sql-driver/[email protected]/connection.go:345 +0xe5
github.com/go-sql-driver/mysql.(*mysqlConn).Exec(0xc000078120, 0xc0000200f0, 0x23, 0x13f0c40, 0x0, 0x0, 0x0, 0x0, 0x8, 0xc0001b9920)
	/Users/skoef/go/pkg/mod/github.com/go-sql-driver/[email protected]/connection.go:327 +0xe5
github.com/go-sql-driver/mysql.(*mysqlConn).ExecContext(0xc000078120, 0x12a3010, 0xc00011c000, 0xc0000200f0, 0x23, 0x13f0c40, 0x0, 0x0, 0x0, 0x0, ...)
	/Users/skoef/go/pkg/mod/github.com/go-sql-driver/[email protected]/connection.go:532 +0x175
database/sql.ctxDriverExec(0x12a3010, 0xc00011c000, 0x8a998d8, 0xc000078120, 0x0, 0x0, 0xc0000200f0, 0x23, 0x13f0c40, 0x0, ...)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/ctxutil.go:31 +0x22e
database/sql.(*DB).execDC.func2()
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:1577 +0x1df
database/sql.withLock(0x12a1718, 0xc0001ec900, 0xc0001b9ce8)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:3294 +0x69
database/sql.(*DB).execDC(0xc000070340, 0x12a3010, 0xc00011c000, 0xc0001ec900, 0xc0001b9e10, 0xc0000200f0, 0x23, 0x0, 0x0, 0x0, ...)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:1572 +0x495
database/sql.(*DB).exec(0xc000070340, 0x12a3010, 0xc00011c000, 0xc0000200f0, 0x23, 0x0, 0x0, 0x0, 0x1, 0xc000102118, ...)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:1557 +0x13c
database/sql.(*DB).ExecContext(0xc000070340, 0x12a3010, 0xc00011c000, 0xc0000200f0, 0x23, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:1535 +0xe5
database/sql.(*DB).Exec(...)
	/usr/local/Cellar/go/1.16.5/libexec/src/database/sql/sql.go:1549
main.queriesTest.func1(0xc00011c320, 0xc0001129d0)
	./cmd/client/main.go:320 +0x277
created by main.queriesTest
	./cmd/client/main.go:305 +0x1b4
exit status 2

I will see if I can come up with some minimal code to reproduce this

[atercattus]

Ooops. I will wait for a little for your reproducing, then I will try it myself.

[skoef]

It goes wrong on this line: https://github.com/go-mysql-org/go-mysql/blob/master/server/resp.go#L186

What happens (in my application) is that a client connects to my server and after all kinds of middleware, its query is forwarded to the actual mysql machine and is returned to the client. If this query is a SELECT or anything that builds up a ResultSet, that's fine. But on for instance an INSERT, it should only result in an OK packet. But now that ResultSet is no longer nil, it will always handle it like a resultset in writeResultset.