| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Hannu Krosing <hannu(at)skype(dot)net>, Neil Conway <neilc(at)samurai(dot)com>, Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] psql -A (unaligned format) eats too much |
| Date: | 2006-06-06 14:47:30 |
| Message-ID: | 17223.1149605250@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Harald Fuchs | 2006-06-06 14:47:40 | Re: COPY (query) TO file |
| Previous Message | Jim C. Nasby | 2006-06-06 14:39:19 | Re: [PERFORM] psql -A (unaligned format) eats too much |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2006-06-06 14:52:56 | Re: Some queries starting to hang |
| Previous Message | Tom Lane | 2006-06-06 14:43:25 | Re: Some queries starting to hang |