Now that it is possible for plpgsql functions (and, no doubt, soon
others) to trap errors, I think we need a little bit of discussion
about what kind of restrictions should be put on trapping the
QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely
ordinary error, it would be fairly easy for a carelessly written
function to disable the backend from responding to ^C or
statement_timeout --- it need only catch the error and keep on
processing. On the other hand, it's not impossible to envision
scenarios where you'd like to be able to catch QUERY_CANCELED.
I can see people using that ability in combination with
statement_timeout, in particular.
The compromise that I put into plpgsql for the moment works like this:
1. EXCEPTION WHEN OTHERS THEN matches all error types *except*
QUERY_CANCELED; thus you cannot accidentally catch that error. (When
the EXCEPTION clause does not match the error type, the error just
propagates outward, so QUERY_CANCELED will always force control back
to the idle loop.)
2. But you can explicitly say EXCEPTION WHEN QUERY_CANCELED THEN
if you really want to catch it.
I can see that point #2 might be controversial, and that some might
feel that QUERY_CANCELED should be untrappable, period. Does anyone
want to argue for that? Does anyone think #1 is a bad idea?
There is also an implementation-level issue, which is whether we should
rely on the PLs' individual error handlers (which are mostly yet to be
written) to enforce such policies consistently. As long as
QUERY_CANCELED is the only special case, things aren't too bad, but
if there's any prospect of having more special cases it could get messy.
I thought about inventing a new elevel category, but really that does
not help much, since we'd still be dependent on the error handlers to be
cooperative. (We can't not run the handlers, since there is very likely
state that they *must* undo before losing control.) Anyone see a
cleaner approach?
regards, tom lane
