> >> This bothers me a bit, because in
> >> fact the effects if any of the tested query would have been rolled
> >> back. Not sure we have any choice though. If we expose the error
> >> then we'll have problems with clients not showing the EXPLAIN
> >> results.
>
> > I think we should leave it in top level, throw the error and fix the
> > clients.
> > As I understood, the idea was, that it only does that if you press
^C
> > or query timeout. In this case current clients would also not show
the
> > plan.
>
> Not if the clients are implemented per protocol spec. A
> client cannot assume that sending QueryCancel will make the
> current query fail.
Sorry I don't understand that comment. I did not not say that it must
fail,
but iff it is interrupted (and thus fails) was the case I meant.
You stated, that current clients won't show the explain output if they
get a protocol error response. (Does the protocol not allow both data
and error ?)
We would need to teach clients to output the explain result even if an
error
is returned.
I hold my comment: on ^C we should return the plan and return the error.
We should not misuse automatic subtransactions for this.
Andreas
