New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
database/sql: permit large uint64 as parameters #9373
Comments
It may break compatible of database/sql. Handling uint64 means RowsAffected is possible to become greater than |
You mean LastInsertId(), not RowsAffected, yes? Because I don't see how this would change RowsAffected in any way. |
If did update rows over than positive number of int64, RowsAffected can't be stored count of rows. Right? |
But what's preventing you from updating that many rows today? |
There are databases (sqlite for example) that do not support such large values. If MySQL does support such large values, then the MySQL driver can makes its That is, a MySQL driver that wants to allow large uint64s can do so today. |
The following program, which assumes a local MySQL server and a specific table with one column, will fail.
The error message is
I am not sure why this is enforced, although #6113 gives some hints and says if it's a problem, then it should be discussed. Let's discuss.
I'll start. I believe it is a problem, and quite a serious one. A lot of applications will start out small and eventually need 64-bit counters. People who have been bitten by this a few times will anticipate it and just start out with 64-bit counters, and what the heck, why not use 64-bit unsigned while we're at it. Or, people will use
uint64
to store 64-bit checksums or other 64-bit pieces of data. In the application I work on, we have them all over the place, and a lot of them set the most significant bit. In any case, the problem is that things start out working just fine, and later they explode without warning.We work around this by wrapping those parameters in
fmt.Sprint()
butAnd this will probably never be a solved problem as long as the behavior still exists.
I don't know what to suggest to fix this, since I do not understand what
defaultValueConverter
is used for -- I gather it has a lot of functionality in different contexts.The text was updated successfully, but these errors were encountered: