Truncate internal buffer when rows.Close() is called

[methane]

Description

Fixes #903

Checklist

• Code compiles correctly
• Created tests which fail without the change (if possible)
• All tests passing
• Extended the README / documentation, if necessary
• Added myself / the copyright holder to the AUTHORS file

[DoctorQ]

I run this changes in my project!it's ok and fixed my problem

[julienschmidt]

If I understand golang/go#23519 correctly, the issue is not that buffers can not be reused at all, but that it isn't safe to do so until the next rows.Next() call.
Allocating a new buffer is a horrible bad idea and if database/sql actually would require it, then it would be horrible misdesigned.

[methane]

If I understand golang/go#23519 correctly, the issue is not that buffers can not be reused at all, but that it isn't safe to do so until the next rows.Next() call.

buffer exposed by rows.Next() can't be reused from rows.Close() is called.

Allocating a new buffer is a horrible bad idea and if database/sql actually would require it, then it would be horrible misdesigned.

I agree, but this is caused by adding context support.
And #905 reduces number of allocations.

[methane]

@julienschmidt Please reconsider #905 again. Currently, there is really race when context is cancelled. Race condition is one of most horrible thing in Go.

If we don't fix it soon, we should notice this bug and say "You must not cancel the context passed to
QueryContext" explicitly.