Getting unsigned values for INT column about go-mysql

[karmakaze]

I think what's going on here is with binary replication the 'bits' are meant to be transferred and applied, as signed/unsigned have the same bit pattern, no problem. What the library is doing is being helpful returning int64 for all integral types to reduce the number of type cases to handle. Where this goes off is widening an 8, 16, 24, or 32 signed value.

e.g. return int64(binary.LittleEndian.Uint32(data)) will return values like 4294967295 for -1.

I tested some changes in a fork to always sign-extend while widening (even for the INT24 case to int32 then int64). This worked much better.

I continued on to then return the various int8 thru int64 interface{} types meaning the user will need to expect these. The advantage is that there's no possibility of data mangling (-1 -> 4294967295) and if you want the unsigned version a cast will convert.

I'll see about making a Pull Request to see this. My branch has import package renaming (not yet using Go 1.5 vendor'ing feature) that needs to be tidied before I do so.

Note: There might be a similar issue with date handling for (negative) dates before Jan. 1, 1970, but I didn't really look into that.

[siddontang]

Can we close it now?

[karmakaze]

Thanks for accepting PR#27, we can close the PR. Please also consider PR#28 as well before closing the issue.

The follow-up PR #28 returns smaller (and unsigned) integer or float32 types for interface{}. There's notes there for pros/cons. I think the upside is greater with a slight non-backward compatibility (users have to also handle int8, uint8, float32, etc in addition to int64 and float64).

[siddontang]

Thanks, I will close it and move another. :-)