Add support for retrieving multiple results.

[petermattis]

If the special \next query is executed, the driver looks for another
set of results on the connection. If no such results are found,
ErrNoMoreResults is returned. Also accessible via the conn.Next()
method, though this later interface requires direct interaction with
lib/pq instead of going through the database/sql package.

[tamird]

heh, this was confusing. I guess you force pushed master here.

Is this the same as #1?

[petermattis]

Yeah, I forced-pushed master to reset us to the upstream state. Then realized the error of my ways.

It is almost the same as #1, modulo the conn.Next() interface.

[bdarnell]

Before we merge this I'd like to have a plan for cockroachdb/cockroach#3993. I think that issue is going to require a larger refactoring and a more generic interface on pq.conn, and we might be able to implement next-result fetching without a special query.

My thinking for cockroachdb/cockroach#3993 is that we'd take all of the recv loops that currently exist in the code and replace them with one method that reads until it gets a Z, returning a list of "result" objects (which could be either a sql.Result or an sql.Rows). simpleExec, simpleQuery and friends could be implemented in terms of this method, and our CLI would call it directly.

[petermattis]

My plan for cockroachdb/cockroach#3993 is less invasive. Currently pq.rows.Next ignores the "command complete" tag (C). I think what we need to do is to give to have it parse the command complete tag (using parseComplete) and provide an API for retrieving the rows affected info.

I'd like to avoid returning a list (slice?) of result or row objects from a single method call. Doing so requires buffering all of the results in memory instead of streaming them off the wire. Is there a particular problem with the conn.Next() interface.

[bdarnell]

There's not a particular problem with Next; it's just a little ugly that it's implemented with a magic query string under the hood. Good point about the buffering; that rules out returning a sequence of results.

I still think it would be a little cleaner if the recv() loop were in Next() and simpleQuery were implemented in terms of Next rather than the other way around. I'm imagining that simpleExec (and the more complex versions) could be unified into Next but maybe that would be tougher than it looks.

LGTM

[petermattis]

The only purpose of the magic query now is for conn_test.go changes. I could make the magic query string an implementation detail (there is no need to export it).

[bdarnell]

I'm less concerned about exporting the query string than the direction of the relationship between simpleQuery and Next. But let's leave it unexported so we have the option of changing the implementation in the future.

[petermattis]

Ok, unexported the magic query string and renamed to nextResultQuery to avoid some confusion with the nextResult variable in conn.simpleQuery.