Re: Alternative new libpq interface.

On Thu, 6 Jul 2000, Tom Lane wrote:

> Chris Bitmead <chrisb@nimrod.itg.telstra.com.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.

Agreed, which was why I had suggested going to a libpq2 and leaving the
current libpq intact ... but, I was always confused as to why pq vs pg, so
Chris going to a libpg.a sounds like a really nice way to accomplish this
without causing any headaches with 'legacy apps' that are tied to libpq
...

What I'd suggest is leave libpq in for a few releases, until libpg
stabilizes and then look at removing it and directing ppl over to libpq
...