/cc @kardianos

Could you provide an example please?

@kardianos the file attachment in my original post has more detail. The TLDR version:

type SomeData struct {
    prop1 int
    prop2 *int
}

myData := new(SomeData)

// Error
err = db.QueryRow('SELECT 1, 2').Scan(&myData.prop1, myData.prop2)

// No error, note address of operator on pointer variable.
err = db.QueryRow('SELECT 1, 2').Scan(&myData.prop1, &myData.prop2)

I suspect a lot of people use the latter implementation to avoid returning the nil pointer error but I think a more practical solution might be for convertAssign to allocate nil pointers instead of returning an error. The attachment in my original post also has some code for types that implement the Scanner interface.

Thank you for your clarification. I'm unsure if that's what we want to do or not. The first step would be to see how involved this change would be and what the runtime cost would be to do this.

If you have

func f(x *int) { ... }

and call

var y *int = nil
f(y)

there is just no way for f to do anything to cause the definition of y in the caller's context to become non-nil. f doesn't know where the argument came from nor does it have any way to get back to the "source" and change it. You'd have to write f(**int) and call f(&y).

It seems like that's what you're asking Scan to do here. Am I missing something?

@rsc , yes you are correct. There is nothing we can do here in this case. I was not thinking correctly when I posted my last comment.

@rsc, @kardianos, Thanks for the clarification. Could anything be added to the documentation to clarify behavior when dest is a pointer type? We end up with inconsistent client side code when developers randomly mix Scan(i) and Scan(&i) when i is of type *int.

I admit I don't understand lower level implementation well but perhaps something like "If dest is a nil-pointer, Scan returns sql.errNilPtr. If dest is a pointer to a pointer, Scan attempts to indirect dest."

@220kts The issue is a bit more fundamental then that.
Take: type User struct { ID *int } , if you pass in rows.Scan(user.ID), it is the same as passing in rows.Scan(0) (nil pointer). We could create it and assign it, but we could never "return" it because you don't have the address to use it after we assign it. Does that make sense?

@kardianos Yes, thanks. The part we struggle with - due to limited understanding, we're application developers - is inconsistent client side code. Often our developers know in a certain context user.ID is not nil so they write rows.Scan(user.ID) and it works. In other context user.ID may be nil so they write rows.Scan(&user.ID) and it also works.

This discussion clarified the issue for me personally but perhaps some additional verbiage or an example with pointer types in the documentation might be useful for other developers as well?

I don't think there is anything to really add on database/sql side. Though I could be wrong.

I think this might be just better understanding points. It is tempting to use a pointer as a NULLABLE value in Go. I've done it myself. However, when at all possible I actually try to avoid using pointers to facilitate database NULL values. Database NULL and Go nil arguably convey different concepts: Go nil / pointers point to another value and remove the value from the current struct. The database NULL says the value is not be present.