Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
proposal: database/sql: support more nullable types #31231
I'm not entirely sure why the database/sql package requires using special types to represent nullable fields, as opposed to plain old pointer types. Why don't all of the built-in Go types just feature sql.Scanner implementations, including arbitrarily deep pointers?
In any case, the API here is limited to a paltry set of types, compared to the full set of built-in types actually available to Go. We are missing nullable:
Sure, we can probably skip over complex numbers due to SQL generally not supporting complex numbers as standard types. But the aforementioned types are very common to use, so it would be better to round out the halfway marshaling and actually support these. As of now, users have to write a lot of custom code to manually marshal and truncate these types, with plenty of risk for error compared to built-in API's.
I'd like to make a better API for passing values out and I've sketched some ideas out, but nothing final yet.
If you want to make a case for having a NullRune type or if you want to do a survey of databases that support complex structures like JSON, please do so.
I have other strategies I used to avoid these problems in general, so feedback on this area is great. Thanks!
NullTime is on its way. The others seem very specialized. I don't even know how we would handle all structs.
Note that for an arbitrary type T, the way to write sql.NullT is
We can leave this on hold for generics but probably the answer is just use a pointer type. Those are nullable automatically.
@kardianos the main internally-defined sql.Scanner/driver.Value type we use all over the place is NullInt32. This is because we want to use a 32-bit integer in our code for IDs which are 32 bits in the DB. So (in postgres):
(Naturally we prefer NullInt32 to turning a bunch of small integers into pointers.)
It is common for database integers to be represented as int32 internally. Although NullInt64 is already defined, this should remove some type casts and make working with those eaiser. For #31231 Change-Id: Ia0c37ecef035fee0734c1d1fb6f58aef6905cf5e Reviewed-on: https://go-review.googlesource.com/c/go/+/174178 Run-TryBot: Daniel Theophanes <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org>
I use it like this
and wrap results from database