X-Original-To: pgsql-interfaces-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 602859FB215 for ; Tue, 19 Sep 2006 00:04:38 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 63094-03-2 for ; Tue, 19 Sep 2006 03:03:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by postgresql.org (Postfix) with ESMTP id 94AB89FA375 for ; Tue, 19 Sep 2006 00:03:05 -0300 (ADT) Received: from webmail.xs4all.nl (dovemail8.xs4all.nl [194.109.26.10]) by smtp-vbr3.xs4all.nl (8.13.6/8.13.6) with ESMTP id k8J330qV057263; Tue, 19 Sep 2006 05:03:00 +0200 (CEST) (envelope-from jtv@xs4all.nl) Received: from 203.121.164.162 (SquirrelMail authenticated user jtv) by webmail.xs4all.nl with HTTP; Tue, 19 Sep 2006 10:03:04 +0700 (ICT) Message-ID: <11882.203.121.164.162.1158634984.squirrel@webmail.xs4all.nl> In-Reply-To: <450E5006.8020603@microbizz.nl> References: <450A6A87.2030808@microbizz.nl> <450AA301.9020408@microbizz.nl> <6009.125.24.242.104.1158397058.squirrel@webmail.xs4all.nl> <450D21E9.7060807@microbizz.nl> <16217.125.24.243.247.1158490996.squirrel@webmail.xs4all.nl> <450E5006.8020603@microbizz.nl> Date: Tue, 19 Sep 2006 10:03:04 +0700 (ICT) Subject: Re: Progress of asynchronous queries From: "Jeroen T. Vermeulen" To: "Adriaan van Os" Cc: pgsql-interfaces@postgresql.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by XS4ALL Virus Scanner X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.135 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200609/21 X-Sequence-Number: 6266 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