Probable bug in database/sql

122 views
Skip to first unread message

Marco De Zio

unread,
Feb 21, 2024, 7:28:01 PMFeb 21
to golang-nuts
It seems to me that the second flag returned by Rows.nextLocked is wrongly interpreted by Rows.Next as it sets rs.hitEOF = true when ok is false; also Rows.nextLocked should set ok to true in some of the cases where right now returns false.


Am I wrong ?

Ian Lance Taylor

unread,
Feb 21, 2024, 8:56:37 PMFeb 21
to Marco De Zio, golang-nuts
The "ok" result of nextLocked is intended to report whether, when the
method returns, the Rows is pointing at valid data. The "doClose"
result reports whether the Rows should be closed. Given that
understanding, the behavior of Next looks reasonable to me.

As it happens when the current implementation returns "doClose" as
true, it always returns "ok" as false. So the test "if doClose &&
!ok" is not strictly necessary; it could be replaced with "if
doClose". But the current code doesn't seem wrong to me.

Can you show a code sequence that seems buggy to you?

Ian

Marco De Zio

unread,
Feb 22, 2024, 9:04:58 AMFeb 22
to golang-nuts
Thank you for the quick response!

Let me elaborate a bit: my doubt arose from the hitEOF doc string which says that it's expected to be true when there are no more rows AND no errors where encountered; within Next, hitEOF is set to true when nextLocked's ok is false. That seems misleading to me as it's set to true even if "Rows is NOT pointing to a valid data" (or whatever error the driver's Next may return).

Now that I've also looked a bit more into it I can see that it's not really buggy as Rows.Err will still report the right error and hitEOF is used only for the closing context error, but that code still smell bad to me due to that description.
Reply all
Reply to author
Forward
0 new messages