Fetches all rows by default on query, like libpq.

[RangelReale]

This allows multiple queries to be active simultaneously
Provides a singlerowmode=true parameter, like libpq (to keep working like today)

fixes #81

[kisielk]

Why not just [][]driver.Value here?

[RangelReale]

Aren't slices costly to append? As I can't know beforehand how many records there will be.

[kisielk]

append behaviour is fairly reasonable, it doesn't just grow the slice by one each time you append. list.List also uses reflection, so there's a performance hit from that.

http://play.golang.org/p/SybwNAQOQ9

PASS
BenchmarkSlice1000     10000        125335 ns/op
BenchmarkSlice10000     1000       2363422 ns/op
BenchmarkSlice100000          50      28006284 ns/op
BenchmarkSlice1000000          5     273778224 ns/op
BenchmarkSlice10000000         1    3812814581 ns/op
BenchmarkList1000       5000        468516 ns/op
BenchmarkList10000       500       5936557 ns/op
BenchmarkList100000       20      70525959 ns/op
BenchmarkList1000000           5     737343756 ns/op
BenchmarkList10000000          1    8153616298 ns/op
ok      bench   31.456s

[RangelReale]

Good to know, I updated my fork.

[johto]

-  return &rows{st: st}, nil
+  r := &rows{st: st}
+  if st.cn.singlerowmode {
+    return r, nil
+  } 

Isn't this the wrong way round? Inverting the condition seems to fix the problem with regression tests failing.

Also, is reverting 31326ad really necessary? As far as I can tell, you never have two queries actually running on the protocol level, so I don't see how it would cause any problems.

[RangelReale]

Hmm I made a pull request using my master branch, now GitHub got my latest changes which weren't meant to be here.

The revert needed to be done because the scrath buffer was getting overriten when 2 queries were done at the same time, parts of the resultset for one query were appearing on the other one.

[johto]

Oh, I think I now see how that could happen.

I think instead of making everyone pay the performance penalty from reverting that commit, you should only impose it on people using the singlerowmode by copying the data before releasing the connection back into the pool.

Also, is there a specific reason you chose not to implement the sql.Rows interface for rowscomplete?

[johto]

Also, is there a specific reason you chose not to implement the sql.Rows interface for rowscomplete?

Oh, looks like you're not even supposed to; database/sql should take care of that. Scratch that part.

[timbunce]

@RangelReale any chance you could update this PR?

The current code changes the behavior to fetch-all from the current implicit 'single-row mode'. If you also inverted the option so the current behaviour was maintained by default I think you'd address the concerns raised in #81 and stand a better chance of getting this merged.