From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | "Adriaan van Os" <adriaan(at)microbizz(dot)nl> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Progress of asynchronous queries |
Date: | 2006-09-19 03:03:04 |
Message-ID: | 11882.203.121.164.162.1158634984.squirrel@webmail.xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Mon, September 18, 2006 14:51, Adriaan van Os wrote:
> Still, the issue I raised was about tracing the progress of a SQL command
> in general, not about the
> specific case of using a cursor instead.
True, and dealing with cursors is extra work in libpq.
In the C++ API OTOH there is a class that lets you treat a cursor more or
less as a regular query result. It's set to be replaced with a more
modern version, but it's usable: chunks of result data are fetched on
demand, i.e. as you access them. If you had something like that, all
you'd have to do is issue your query as before, process your data as
before, and update your progress display after every n rows of processing.
You wouldn't really notice any of the complexity underneath.
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | Jan van der Weijde | 2006-09-20 12:38:23 | PQsetdbLogin() and PQconnectdb() fail on HPUX11i 64 bits with empty servername |
Previous Message | D'Arcy J.M. Cain | 2006-09-18 23:05:06 | Re: Python interfaces |