X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 9FEB2DB73B for ; Wed, 16 Nov 2005 05:35:12 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 55173-06 for ; Wed, 16 Nov 2005 09:35:12 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from gauss.credativ.com (ipx11302.ipxserver.de [212.112.227.254]) by svr1.postgresql.org (Postfix) with ESMTP id C5767D8D7D for ; Wed, 16 Nov 2005 05:35:08 -0400 (AST) Received: from [192.168.100.56] (p54B16606.dip.t-dialin.net [84.177.102.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by gauss.credativ.com (Postfix) with ESMTP id 83C66D764C; Wed, 16 Nov 2005 10:35:08 +0100 (CET) From: Peter Eisentraut To: pgsql-interfaces@postgresql.org Subject: Re: Incremental results from libpq Date: Wed, 16 Nov 2005 10:34:58 +0100 User-Agent: KMail/1.8.2 Cc: Tom Lane , Scott Lamb References: <4D426B54-E08F-4DE9-9776-D46610CA4968@slamb.org> <19391.1131571328@sss.pgh.pa.us> In-Reply-To: <19391.1131571328@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511161034.58561.peter_e@gmx.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200511/26 X-Sequence-Number: 5822 Am Mittwoch, 9. November 2005 22:22 schrieb Tom Lane: > The main reason why libpq does what it does is that this way we do not > have to expose in the API the notion of a command that fails part way > through. I'm at LinuxWorld Frankfurt and one of the Trolltech guys came over to talk to me about this. He opined that it would be beneficial for their purpose (in certain cases) if the server would first compute the entire result set and keep it in the server memory (thus eliminating potential errors of the 1/x kind) and then ship it to the client in a way that the client would be able to fetch it piecewise. Then, the client application could build the display incrementally while the rest of the result set travels over the (slow) link. Does that make sense?