Re: Alternative new libpq interface.

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> 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).

Bear in mind that "avoiding the features you don't want" is not
cost-free. In particular, I have seen no discussion in this thread
of the implications that streaming read would have for error handling.

In the current libpq, you either get a complete error-free result set
or you don't. If there is to be a streaming interface then it must
take into account the possibility of an error partway through the
fetch. Applications that use the interface will also incur extra
complexity from having to undo whatever they might have done with
the initial part of the result data.

Still, something along the lines of your sketch seems worth pursuing.
Personally I've never once had any use for the "random access to result
set" aspect of libpq's API, so it seems like buffering the whole set
is a pretty high price to pay for a small simplification in error
handling.

My gut feeling about this is that if a complete rewrite is being
considered, it ought to be done as a new interface library that's
independent of libpq. libpq has its limitations, but it's moderately
well debugged and lots of apps depend on it. A rewrite will need time
to stabilize and to attract new apps --- unless you want to guarantee
100.00% backward compatibility, which I bet you won't.

regards, tom lane