Tom Lane <tgl@sss.pgh.pa.us> writes:
> After we've printed the results, we have a bit of a problem: if
> ExplainCancelPending is set, we now need to abort the transaction. It
> would not do at all to allow an incompletely executed UPDATE to commit.
> I experimented with throwing an elog() at the bottom of ExplainQuery()
> after end_tup_output(), but this does not work: psql only prints the
> error and not the data, because libpq throws away the query result
> upon seeing the error. We could probably hack psql to print the results
> before noting the error, but I'm concerned about making a change that
> would change the behavior for other error-at-end-of-statement cases.
> Also, it's not clear what might have to happen to get non-psql clients
> to play along.
Would it be possible to make a whole new protocol message for EXPLAIN results?
The reason I'm suggesting that is because it might make it easier to implement
the SIGINFO handler that sends incremental EXPLAIN results on demand that I
was describing earlier.
Then libpq would have a separate api call to check for EXPLAIN results. If a
non-psql client doesn't check it then it doesn't get the EXPLAIN results but
the behaviour is correct. If it does then it can get the EXPLAIN results.
This might also let you run with EXPLAIN ANALYZE instrumentation but still get
the regular query results. Since the explain analyze results would still be
available out of band.
--
Gregory Stark
T + 514 938 2456
