Change https://golang.org/cl/344410 mentions this issue: database/sql: add NullUint64

Today we have:

type NullBool struct{ ... }
type NullByte struct{ ... }
type NullFloat64 struct{ ... }
type NullInt16 struct{ ... }
type NullInt32 struct{ ... }
type NullInt64 struct{ ... }
type NullString struct{ ... }
type NullTime struct{ ... }

Are you suggesting we add all the uint sizes, or just uint64? Why?

Hey @rsc and thanks for responding.

The NullUint64 is required for ent atm to support scanning null uint64 values because using NullInt64 returns a value out of range error if the value is greater than 2^63−1.

If you see any concern with adding the rest of the unit types, it can wait for the "generics" change, because they can be implemented externally with NullUint64.

Most SQL databases don't support uints; though some do. I would recommend we wait for a generic version to land. I was working on one when I encountered a compiler error at tip; once that is resolved I can look into it more.

I recommend against this proposal.

Thanks for the feedback @kardianos 🙏

I don't think it matters if the database supports unsigned integers or not, it can also be defined as (numeric(20,0) check (c >= 0 and c <= 2^64-1)), and we should still be able to scan its value to the native uint64 type without using an external package.

Currently, Rows.Scan (convertAssignRows) does work with uint64, but if the column is nullable, we have no way to work around this except for using the sql.convertAssign function directly or copying it.

As I mentioned above, unlike NullByte and NullInt16 (that were added by me on 1.17), the NullUint64 type can't be implemented easily outside the sql package, and I don't think we should be blocked for at least a year until generics will be stable.

NullUint64 seems fine in isolation and is the only sized unsigned int type that can't be shoehorned into a signed type instead. @kardianos are you OK with adding NullUint64, or do you want to wait for a generic Null[T]?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Thanks for opening this @a8m, on behalf of the Ent community I join your proposal 🙏

@rsc I would prefer to wait for a generic Null. Unsigned types are not common in databases.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Unsigned types are not common in databases.

Hey @kardianos and @rsc, please read my previous comment. It's unrelated to the fact that MySQL and MariaDB support unsigned integers. The motivation to support NullUint64 comes from the application perspective. Applications should be able to scan nullable values to unsigned integers. uint64 is already supported by convertAssign, but since this function is not exported, NullUint64 can't be implemented externally like the otherNull<T> types, because they use this function.

No change in consensus, so declined.
— rsc for the proposal review group