X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 415879FA2E6 for ; Tue, 6 Jun 2006 11:39:33 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 00653-10 for ; Tue, 6 Jun 2006 11:39:22 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 03FD89F9316 for ; Tue, 6 Jun 2006 11:39:22 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 28B9B56445; Tue, 6 Jun 2006 09:39:21 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 6 Jun 2006 09:39:19 -0500 Date: Tue, 6 Jun 2006 09:39:19 -0500 From: "Jim C. Nasby" To: Tom Lane Cc: Hannu Krosing , Neil Conway , Zoltan Boszormenyi , Andrew Dunstan , Mark Woodward , pgsql-hackers@postgresql.org Subject: Re: [PERFORM] psql -A (unaligned format) eats too much Message-ID: <20060606143918.GA53487@pervasive.com> References: <20512.1149521250@sss.pgh.pa.us> <20060605155349.GU53487@pervasive.com> <20813.1149523235@sss.pgh.pa.us> <18006.24.91.171.78.1149526092.squirrel@mail.mohawksoft.com> <44845E86.3080001@dunslane.net> <4484672B.8080606@dunaweb.hu> <1149529945.5577.5.camel@localhost> <21820.1149531024@sss.pgh.pa.us> <1149597013.3818.7.camel@localhost.localdomain> <15738.1149601723@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15738.1149601723@sss.pgh.pa.us> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060606:tgl@sss.pgh.pa.us::IeqOyeBvwIr3qK7H:00000000000000000000 0000000000000000000000002Xge X-Hashcash: 1:20:060606:hannu@skype.net::yUnFvt32cQeHu5v2:00632O X-Hashcash: 1:20:060606:neilc@samurai.com::o3NIm7wJzH7s4+v+:00000000000000000000 0000000000000000000000001mQD X-Hashcash: 1:20:060606:zboszor@dunaweb.hu::cpUr4OxPL/l5KtUL:0000000000000000000 0000000000000000000000001ZQb X-Hashcash: 1:20:060606:andrew@dunslane.net::aQFcjJ690KAEXHms:000000000000000000 0000000000000000000000001D7h X-Hashcash: 1:20:060606:pgsql@mohawksoft.com::dx+bBOzb4jmPKkfF:00000000000000000 0000000000000000000000004djV X-Hashcash: 1:20:060606:pgsql-hackers@postgresql.org::AcVER4DL5bdrLdMD:000000000 0000000000000000000000000LBu X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/193 X-Sequence-Number: 84426 On Tue, Jun 06, 2006 at 09:48:43AM -0400, Tom Lane wrote: > Hannu Krosing writes: > > Ühel kenal päeval, E, 2006-06-05 kell 14:10, kirjutas Tom Lane: > >> Note of course that such a thing would push the incomplete-result > >> problem further upstream. For instance in (hypothetical --cursor > >> switch) > >> psql --cursor -c "select ..." | myprogram > >> there would be no very good way for myprogram to find out that it'd > >> been sent an incomplete result due to error partway through the SELECT. > > > would it not learn about it at the point of error ? > > No, it would merely see EOF after some number of result rows. (I'm > assuming you're also using -A -t so that the output is unadorned.) So if an error occurs partway through reading a cursor, no error message is generated? That certainly sounds like a bug to me... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461