Expose mysql info from ok packets

[enknamel]

I am not sure if this is possible with the current go database library (unless you do some terrible hack) but I would love to be able to make use of the info string at the end of the ok packet since it can can contain some very useful data such as rows matched. Would this be possible to do?

[arnehormann]

We'll have to discuss this, it really doesn't fit as is. I'm guessing it won't land in the immediate future, but don't give up yet...

[julienschmidt]

The number of rows matched is available at least for Exec: https://github.com/go-sql-driver/mysql#clientfoundrows

Exposing additional data is very hard, since we can not define new functions on Result or Rows.
The database/sql package wraps the structs returned by the driver. With the current implementation it is impossible to get a reference to the mysqlRows wrapped by sql.Rows in a sensible way.

@arnehormann managed to get it via reflection, but this might break with any change in the database/sql package. I do not want to include unstable stuff like this in the driver.

[arnehormann]

@julienschmidt I think what he wants is a string never even read which would be read at the end of this function: https://github.com/go-sql-driver/mysql/blob/master/packets.go#L484 (string info, payload after warning count).

There's no way to get that with reflection and that's not what I did.

Still, I fully intend to write a CL for Go to fix https://code.google.com/p/go/issues/detail?id=5606 as soon as the current freeze is lifted. That would make my sqlinternals package obsolete.

[julienschmidt]

I'm assuming we would read and store it somewhere in Result / Rows

[arnehormann]

Ah - I missed that you assumed an already changed function which stored it.

I thought about an api that gives access or hooks into the low level []byte of a packet - without additional parsing for the driver itself. That could lead to corruption and memory problems, but that's on the user of that api.