Horton

Re: psql - add SHOW_ALL_RESULTS option

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
Cc: "Alvaro Herrera" <alvherre@2ndquadrant.com>, "Tomas Vondra" <tomas.vondra@2ndquadrant.com>, "Fabien COELHO" <coelho@cri.ensmp.fr>, "vignesh C" <vignesh21@gmail.com>, "Kyotaro Horiguchi" <horikyota.ntt@gmail.com>, peter.eisentraut@2ndquadrant.com, iwata.aya@jp.fujitsu.com, "PostgreSQL Developers" <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-17T19:10:26Z
Lists: pgsql-hackers 
"Daniel Verite" <daniel@manitou-mail.org> writes:
> Yes. For instance if the stored procedures support gets improved to
> produce several result sets, how is psql going to benefit from it
> while sticking to the old way (PGresult *r = PQexec(query))
> of executing queries that discards N-1 out of N result sets?

I'm not really holding my breath for that to happen, considering
it would involve fundamental breakage of the wire protocol.
(For example, extended query protocol assumes that Describe
Portal only needs to describe one result set.  There might be
more issues, but that one's bad enough.)

When and if we break all the things that would break, it'd be
time enough for incompatible changes in psql's behavior.

			regards, tom lane

Commits

  1. psql: Show all query results by default

  2. psql: Refactor ProcessResult()

  3. psql: Refactor SendQuery()

  4. psql: Add test for psql behavior on server crash

  5. psql: Additional tests

  6. Improve some psql test code

  7. psql: Fix some scan-build warnings

  8. psql: Add test for handling of replication commands

  9. psql: More tests

  10. psql: Add various tests

  11. psql: Add test for query canceling

  12. Revert "psql: Show all query results by default"

  13. Extend a test case a little