Mysql: Provide uint32 and uint64 types

Created on 28 Nov 2017 · 7Comments · Source: go-sql-driver/mysql

Issue description

When using regular MySQL INT type as primary key, users usually create type with INT UNSIGNED which is 32b unsigned int. There is however no such type in basic db.sql package.

I discussed this on reddit and everyone suggested to write this type. However it seems to me this should be in a library to be reused. I think it should be in this library, since it is MySQL specific type (the byte sizes are) and I don't think we could push it to db.sql package.

I believe the structs should correctly represent the data types in MySQL so there are no overflows, which would happen when using NullInt64 to save data into INT UNSIGNED. Same applies when using BIGINT UNSIGNED - whose maximum value will not fit into NullInt64.

Example code

type MyTable struct {
    ID uint
}

type MyOtherTable struct {
    ID uint
    MyTableID mysql.NullUint32 // Nullable relationship with MyTable
}

I could create these types, I just wanted to ask before writing them if you'd be ok with them being in this package.
Thank you.

databassql issue enhancement question

Source

lunemec

👍1

Most helpful comment

@arnehormann there was a discussion about this in Go database/sql package github, where rsc said this support should be added in golang mysql driver specifically (because not all databases support these large values).

See here: https://github.com/golang/go/issues/9373

lunemec on 1 Dec 2017

👍16

All 7 comments

We are bound by https://golang.org/pkg/database/sql/driver/#Value - and the driver is communicating with database/sql within these constraints. Except for NullTime which was missing in database/sql, we won't add additional types.

arnehormann on 29 Nov 2017

See here: https://github.com/golang/go/issues/9373

lunemec on 1 Dec 2017

👍16

Yep, he wrote:
```There are databases (sqlite for example) that do not support such large values.
That is why database/sql does not allow this by default.
We cannot change that decision now, because it will break all existing drivers.

If MySQL does support such large values, then the MySQL driver can makes its
implementation of driver.Stmt implement driver.ColumnConverter and allow
uint64s in a custom ValueConverter.

That is, a MySQL driver that wants to allow large uint64s can do so today.
There's no code change needed in database/sql.
```

I agree, this is needed, even more importantly for uint32 rather than uint64, because uint64 is less likely to overflow anytime soon.
How do we make it happen? I am willing to help with creating a pull request for this.

mastertheknife on 22 Sep 2020

We already support uint64.

methane on 23 Sep 2020

We already support uint64.

But not NullUint64, which should be used for BIGINT UNSIGNED nullable field.
Need to use NullInt64 instead, which can trigger overflow.

mastertheknife on 23 Sep 2020

You mentioned rsc's comment about uint64 so I replied it is implemented already as rsc suggested.
If you are proposing NullUint64 instead of uint64, say so without mentioning rsc's comment. It is just confusing.

methane on 23 Sep 2020

We already support uint64.

But not NullUint64, which should be used for BIGINT UNSIGNED nullable field.
Need to use NullInt64 instead, which can trigger overflow.

I created a package that solves that kind of problem

https://github.com/Thor-x86/nullable