Even more disturbing example:

var scan1 float64
var scan2 interface{} = float64(0)
err := db.QueryRow("SELECT 3.14, 3.14").Scan(&scan1, &scan2)
if err != nil {
	t.Fatal(err)
}
t.Logf("%v (%T) %v (%T)", scan1, scan1, scan2, scan2)

3.14 (float64) 3.14 (string)

Poke @kardianos

@AlekSi Are you using sqlite? If not, what DB storage are you using.

What you are noticing is the underlying type the database provides is coming though in scan2. You see, even when you assign a float64 or int8 to an interface{} type, the type is still an interface type. It just happens to have something stored in it already. We don't check for what is already stored in it, we just look at the type.

The exact SQL used would depend on the system used, but for postgresql you could use select cast(3.14 as double precision), cast(3.14 as double precision); and it would be a float64 in either case. Postgres doesn't have an int8 type exactly, but SQL Server does called tinyint and that would be select convert(tinyint, 42), convert(tinyint, 42); which again would scan both as the same type.

You may already know all this. Then the question is, why would you like to do this? What is your goal? Do you want a generic or runtime configurable converter? If so, you could use something like this https://godoc.org/bitbucket.org/kardianos/table to pull data out, then have a custom routine that converts to your appropriate data type. What is the problem you want to solve?

Sorry, I wasn't clear enough in my original message. I'm writing my own driver for MySQL X Protocol: https://github.com/AlekSi/mysqlx I noticed the behavior explained in the first message while writing tests. I think it is not very intuitive, although I also don't think my situation is very typical in real non-test non-driver code.

Sorry for the delay @AlekSi Looking at the original example, scan1 has a Go type of int8, while scan2 has a Go type of interface{} (fmt.Spritf("%T") does a bit of reflection to look at the type stored in interface{}). I'm not convinced we want to look at what is currently stored in a type to determine how something should be scanned (which is what you are asking for I think).

For your second example with float64 scanning, after looking through convertAssign, I can only assume that you are returning a Go string type from the driver and convertAssign is converting it to float64 in the scan1 case and directly assigning the string to the interface in the second case.

Do you think convertAssign should do something different?

For your second example with float64 scanning, after looking through convertAssign, I can only assume that you are returning a Go string type from the driver and convertAssign is converting it to float64 in the scan1 case and directly assigning the string to the interface in the second case.

It turned out that my driver code handles float numbers coming from database correctly, but in case of unqualified SELECT 3.14 mysqlx really returns BYTES DECIMAL (edited).

I don't think anything should be done for this issue. Thank you.