That's true. However I also like to not mess around with any deferred functions that have to capture an error variable by name (named returns) or by pointer so

That's true. However I also like to not mess around with any deferred functions that have to capture an error variable by name (named returns) or by pointer so that it can modify the error on the way out. Calling rows.Close() after you're done with rows is a simple 4-line addition that doesn't require rewriting the already existing defer rows.Close(), which lowers the cognitive load in my opinion. Like you said, the performance gains (if any) are probably not going to matter when a database call is involved.