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 769D89FA43C for ; Tue, 6 Jun 2006 11:47:50 -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 04005-05 for ; Tue, 6 Jun 2006 11:47:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 783039FA2E6 for ; Tue, 6 Jun 2006 11:47:41 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k56ElUVh017224; Tue, 6 Jun 2006 10:47:30 -0400 (EDT) To: "Jim C. Nasby" 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 In-reply-to: <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> <20060606143918.GA53487@pervasive.com> Comments: In-reply-to "Jim C. Nasby" message dated "Tue, 06 Jun 2006 09:39:19 -0500" Date: Tue, 06 Jun 2006 10:47:30 -0400 Message-ID: <17223.1149605250@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/194 X-Sequence-Number: 84427 "Jim C. Nasby" writes: > On Tue, Jun 06, 2006 at 09:48:43AM -0400, Tom Lane wrote: >>> 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. > So if an error occurs partway through reading a cursor, no error message > is generated? That certainly sounds like a bug to me... Sure an error is generated. But it goes to stderr. The guy at the downstream end of the stdout pipe cannot see either the error message, or the nonzero status that psql will (hopefully) exit with. You can theoretically deal with this by having the shell script calling this combination check psql exit status and discard the results of myprogram on failure, but it's not easy or simple. regards, tom lane