Re: Proposed new libpq API - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Proposed new libpq API
Date
Msg-id Pine.BSF.4.21.0007051106420.33627-100000@thelab.hub.org
Whole thread Raw
In response to Re: Proposed new libpq API  (Chris Bitmead <chris@bitmead.com>)
List pgsql-hackers
On Wed, 5 Jul 2000, Chris Bitmead wrote:

> The Hermit Hacker wrote:
> > 
> > Okay, first thing off the top of my head ... how does this deal with
> > backward compatibility, or have we just blown all old apps out to fhte
> > water?
> 
> There's no issue with compatibility, unless you can see one. It's all
> backwards compatible.

Okay, I'm definitely missing something then ...

> > > Currently you might read results like this...
> > >
> > > PGresult *res = PQexec("select * from foo");
> > > for (int i = 0; i < PQntuples(res); i++) {
> > >   printf("%s\n", PQgetValue(res, i, 0);
> > > }
> > >
> > > It has the disadvantage that all the results are kept in memory at
> > > once. This code would in the future be modified to be...
> > >
> > > PGresult *res = PQexec("select * from foo");
> > > for (int i = 0; i < PQntuples(res); i++) {
> > >   printf("%s\n", PQgetValue(res, i, 0);
> > >   PQflush(res) // NEW NEW
> > > }
> > >

What is the PQflush() for here?  I took it to mean that it was required,
but then reading further down, it just sounds like it flushs what's
already been used and would be optional?

Doesn't this just do what CURSORs already do then?  Run the query, fetch
what you need, etc?



pgsql-hackers by date:

Previous
From: eisentrp@csis.gvsu.edu
Date:
Subject: Re: PQprint
Next
From: Tom Lane
Date:
Subject: Re: Changes to handling version numbers internally