Add AppendRows helper

[espadolini]

I found myself using CollectRows and appending the results immediately into a different slice, and I thought that a small tweak to the helper function to make it append to an existing slice would make it more useful in general.

[jackc]

Seems reasonable at first glance. But it does make me wonder if combining the queries with UNION ALL would be a better solution for multiple queries that have the same shape result. That would allow all queries to run in a single round trip.

[espadolini]

That only works if the actual SQL shape is the same tho, whereas I can scan different things with different functions that both return a T, and put them all in the same slice.

It might also be useful to preallocate or reuse a slice's space, by passing a zero-length slice with nonzero capacity, even when only collecting a single query's results.

[jackc]

Good point. 👍

[Juneezee]

After updating from 5.5.1 to 5.5.3, our integration tests failed.

Diff:
--- Expected
+++ Actual
@@ -12,4 +12,3 @@
unknownFields: ([]uint8) <nil>,
- Edges: ([]*edgev1.Edge) {
- }
+ Edges: ([]*edgev1.Edge) <nil>
})

When SELECT * FROM table WHERE ... returns no rows, 5.5.1 returns empty slice:

pgx/rows.go

Line 424 in ba05097

slice := []T{}

5.5.3 returns nil slice:

pgx/rows.go

Line 441 in 6f8f6ed

return AppendRows([]T(nil), rows, fn)

@jackc I believe this is an unintentional change introduced in this PR.

[espadolini]

I don't think that CollectRows was ever documented to return the dangling slice instead of the nil slice when no items were collected, but it's a simple enough fix (just change the call to AppendRows to be AppendRows([]T{}, rows, fn)).

[jackc]

I don't think empty vs. nil slice was promised, but may as well preserve the previous behavior.