Add a trick to handle null sql query results #91
Conversation
|
This is interesting, but I don't know how to think about benefits and drawbacks, or other difference. For example, what happens if there is an error? I think we need a little more narrative to introduce this technique and explain why it wouldn't be an officially recommended technique. If this works fine, why did the database/sql authors create the built-in nullable types? |
There was a problem hiding this comment.
Although I'd naturally expect this to work, I'd like to know if this is part of the package contract or just a side effect of the current implementation. If the former, we should include a link to supporting documentation. If the latter, then we shouldn't include it here, because we'd be encouraging people to depend on the package's internal implementation, as opposed to its well defined interface.
There was a problem hiding this comment.
Looks like this was suggested way before (#32) but was dismissed. Although I don't see this mentioned anywhere in the package documentation, it turns out that this approach is supported. Russ Cox said it golang-nuts that:
There's no effective difference. We thought people might want to use NullString because it is so common and perhaps expresses the intent more clearly than *string. But either will work.
In fact, I found an explicit commit in database/sql that allows for this approach in Exec as well.
Now, the change proposed here is not correct because s, as a *string, doesn't have a String member. You can't do s.String. If s != nil holds, then you use the string as *s, not s.String.
No description provided.