| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Catalin Iacob <iacobcatalin(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [bug fix] Savepoint-related statements terminates connection |
| Date: | 2017-09-08 17:41:19 |
| Message-ID: | 14417.1504892479@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Catalin Iacob <iacobcatalin(at)gmail(dot)com> writes:
> When reading this I also realized that the backend does send responses for
> every individual query in a multi-query request, it's only libpq's PQexec
> that throws away the intermediate results and only provides access to the
> last one.
If you want to see them all, you can use PQsendQuery/PQgetResult.
https://www.postgresql.org/docs/current/static/libpq-async.html
There's a case to be made that we should change psql to use these
and print all the results not just the last one. I've not looked
to see how much work that would be; but now that we're actually
documenting how to script multi-command queries, it might be
a good idea to fix it before too many people have scripts that
rely on the current behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-09-08 17:45:46 | Re: pgsql: Fix assorted portability issues in new pgbench TAP tests. |
| Previous Message | Ashutosh Bapat | 2017-09-08 17:38:47 | Re: Partition-wise join for join between (declaratively) partitioned tables |