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
...
