Re: Alternative new libpq interface.

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>, "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgresql(dot)org>, pgsql-oo(at)postgresql(dot)org
Subject: Re: Alternative new libpq interface.
Date: 2000-07-06 12:33:23
Message-ID: Pine.BSF.4.21.0007060931110.33627-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 6 Jul 2000, Tom Lane wrote:

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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-07-06 12:33:59 Re: 2nd update on TOAST
Previous Message Philip Warner 2000-07-06 12:23:58 Re: 2nd update on TOAST