Re: Proposed new libpq API

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: Proposed new libpq API
Дата
Msg-id Pine.BSF.4.21.0007051106420.33627-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: Proposed new libpq API  (Chris Bitmead <chris@bitmead.com>)
Список 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 по дате отправления:

Предыдущее
От: eisentrp@csis.gvsu.edu
Дата:
Сообщение: Re: PQprint
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Changes to handling version numbers internally