database/sql: Ability to pass nil to sql.Row.Scan and sql.Rows.Scan #41607
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
What version of Go are you using (
go version
)?I have been working with the
database/sql
package and have noticed that it throws an error when trying to pass in nil values to*sql.Rows.Scan
or*sql.Row.Scan
.This ability to be able to pass nil to
Scan
seems trivial as you would only query columns you would actually need. However, sometimes you want to ignore some columns, for cases like using thereflect
package, making a package for other developers, or where your SQL statement can be dynamic on the number of columns it returns.The current way around this issue is a bit messy. You have to make a new variable that is never used again after the call to
Scan
.e.g.
In my opinion, this is against the design language of Go, as it is unclear what that variable is being used for. That ability to pass nil into
Scan
would make more sense.A counter-point to this issue is that
Scan
forces developers to think properly about the SQL statement they are writing (or thestruct
s they've created), as otherwiseScan
throws an error at the developer saying that it can't accept nil values.However, it is extremely frustrating writing such messy code in situations where you might need to ignore a column. Such situations could be where the SQL statement can be dynamic in the number of columns it returns, and the code for handling the rows returned has to process this.
A proposition to fix this would be by default
Scan
would throw an error if a nil value was passed into it, but, if the developer specifies,Scan
could take in nil values. This way we could keep the functionality of Go telling you that you've passed in a nil value, and you could re-evaluate your code, but if necessary the developer can disable this error, and ignore columns (by passing in nil values). This could be done multiple ways, such as two separate functions, or a flag in thesql.Row
andsql.Rows
structs.I don't think it matters how it's implemented, because any way would surely be better than creating an entirely pointless variable.
The text was updated successfully, but these errors were encountered: