> >> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
