Chris Bitmead writes:
> Some people suggested it might be a good idea to define a new
> interface, maybe call it libpq2.
If you want to implement a new C API, look at SQL/CLI in ISO/IEC
9075-3:1999. It would be a shame if we created yet another proprietary
API.
Having said that, I don't follow the reasoning to create a completely new
client library just for streaming results. A lot of work was put in the
existing one, and if you extend it carefully then you might reap the
benefits of that.
Creating a new API is a tedious process that needs to be done very
carefully. And also keep in mind that the majority of users these days
doesn't use libpq directly. All the other language interfaces would have
to be converted, that's a major effort that will never get done. What we'd
end up with are two different APIs that are only half-maintained each. And
a backend that has to support them both.
> The main thing I dislike about the current interface is that it's not
> low-level enough. It won't let me get around the features that I don't
> want (like caching the entire result).
Then factor out the low-level routines and make them part of the API. You
could certainly re-implement the current "get all rows" as "while (rows
left) { row = malloc(); read(&row); }".
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden