112
Martin Stjernholm Wrote:
> Interesting, but I think the right way to implement this - which fits
> better into the current API - is to instead extend the result object
> with functions like more_results() and next_result(). I.e. the same
> result object is used both to page through rows in a single result set
> and to page through several result sets.
I agree with you, that would be the obvious place to put it, but in
order to do so the result would have to contain the connection. It would
potentially lead to problems in usage too, as it would dissociate the
database connection from the results, leading people to attempting to
reuse it before they had properly consumed all the results from the
connection.
> If the result object keeps state in the connection then the right way
> is to return it through a streaming_query() call
Which is not in Pike 7.6 - but I assume the problems I've outlined above
have been addressed for this, so it would be a way forward.
> Looks like a bit too much cut'n'paste here.. ;)
Guilty as charged :o
|